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browsers allow you to efficiently 
manage your resources. 
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...to create, modify, 


You’ll Ever Need manage, browse and 

translate resources such as dialog boxes, bitmaps, icons, 
cursors and menus. 

Increase the productivity of your development work by 
organizing resources into projects and seemlessly integrate 
all the resource editors. 

Reduce the amount of time required to design the user interface 
of your application-use the state of the art visual editors to 
interactively design and modify dialogs, bitmaps, icons, cursors, 
menus, accelerators, string tables and all other resources—or just use 
any of the hundreds of professionally designed resources included. 

Capture images from anywhere on the screen directly into the 
image editor. Create bitmaps, icons and cursors from the captured image. 

Customize the look and feel of your applications— 
directly extract, modify or replace any resource in any program file, 

EXE, DLL—no source code is needed. 

Translate applications into 
foreign languages without 
having access to the applications source code— 
directly modify all messages, menus and dialogs into any national language. 

Edit, copy and paste resources directly into and from any EXE, RES, 
DLL, RC program file. Eliminate the time consuming edit-compile-link 
cycle—increasing your productivity dramatically. 

Migrate your applications to new 32-bit OS/2 2.0 and 
NT applications utilizing the transparent and automatic resource 
translation capabilities. Create your resources once on 
any platform and instantly use them on any other platform. 
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Thanks to its multi-windowing capabilities, 1-2-3 for OS/2 lets you look at your graphs and 
spreadsheet simultaneously. Whether it’s working with a 3D file or bringing in information 
from external databases, the full power of 1-2-3for OS/2 is always within reach. 


Nothing exploits the 
full graphical environment 
of OS/2 8 like Lotus® 1-2-3® 
for OS/2. It’s the only spread¬ 
sheet that takes full advan¬ 
tage of the speed, memory 
and multi-tasking capabili¬ 
ties of OS/2, while offering 
all the power and function¬ 
ality you’ve come to expect 
from 1-2-3. This includes 
Solver and Backsolver, true 
3D worksheets, file-linking 
and access to external 
databases. As well as such 
industry-leading features 
as WYSIWYG (What-You- 

See-Is-What-You-Get) 
and Collections, 
which allows you to 
work with multiple 
cells and ranges 
simultaneously. 

1-2-3 for OS/2 
is also the only spread¬ 


sheet that’s fully compatible with IBM® 
OS/2 version 2.0. And of course, it’s com¬ 
patible with all previous versions of 1-2-3, 
across all platforms. 

For a free demo disk, including 
sample spreadsheets to show you just 
how powerful 1-2-3 for OS/2 is, call 
1-800-TRADEUR Ext. 6565. 


1-2-3 for OS/2 


Loins 


© 1992 Lotus Development Corporation. All rights reserved. Lotus and 1-2-3 are registered trademarks of Lotus Development Corporation. 
IBM and OS/2 are registered trademarks of International Business Machines Corporation. 























































AMKApplications Manager)...the only OS/2 client/server development tool provid¬ 
ing 32-bit applications exploiting the Workplace Shell and accessing data from local LAN 
or remote host databases, AM increases productivity at least 10-fold compared to 
conventional application development languages. AM is currently in use by over 1,000 
organizations worldwide and is the leader in the delivery of proven, live applications. 
You too can experience the power. ..CALL NOW...508*640* 1080. 
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EDITOR'S CORNER 


I believe that we are all in agreement when I claim that with 
regards to version numbers, 2.0 > 3.1. But yet, if we were 
to multiply each by one million we arrive, at the following 
contradiction: 

( 1 , 000 , 000 ) * 2.0 < ( 1 , 000 , 000 ) * 3 . 1 . 

IBM has sold one million shrink wrapped copies of OS/2 and 
comparing this to Microsoft’s first million, there is a profound dif¬ 
ference in the impact that this number has had. Contrary to popu¬ 
lar thought, the above contradiction isn’t based entirely upon the 
efficiency and ability of the Microsoft marketing machine vs. IBM’s 
or solely on the technical merit of Windows. 

When the success of Windows is discussed, there is a small dis¬ 
tinction that is frequently overlooked. Microsoft (MS) would want 
you to believe that with the release of 3.1, they single-handedly re¬ 
vamped the personal computing market. Actually, it wasn’t until 
3.1 became available that the personal computing market had the 
opportunity to revamp itself. 

In the beginning of the silicon era, change was fast, people 
packed up their belongings and moved to the frontiers with trepi¬ 
dation, needing to keep abreast of all of the latest changes. 
Magazines focusing on personal computers kept us informed and 
kept happy. 

After several years, the market grew to enormous proportions. 
Killer apps were few and far between and the value of the mam¬ 
moth computer magazines decreased. People were saturated with 
information and content with the knowledge that their grey matter 
now contained. Change wasn’t as radical and a constant stream of 
new information was not as necessary as it had been. Reporting on 
computers had become stale. Change was necessary and Windows 
provided the trade magazines with an opportunity to convince the 
public that their magazines were needed. 

Windows represented change, it offered magazines a new av¬ 
enue to seduce the reader to continue subscribing. All of the major 
areas of computing had been defined, so it was time to change 
how we interacted with computers. This is where the genius of MS 
lies. They saw the decline in the computing magazine market and 
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revived it. This would explain the overbearing prejudice of 
Windows over OS/2. 

Possibly one of the most honest statements I have read, is the 
general atmosphere about OS/2 supporters, and possibly why we 
are so zealous at times, is from Mark Minasi, which originally ap¬ 
peared in the October issue of COMPUTE: 

“Despite my personal feeling that OS/2‘s success would be a 
very positive thing for the industry, you can’t have missed the 
somewhat defensive tone of this article. The defensiveness arises 
mainly because, while there are reasons to like OS/2 as well as 
reasons to dislike it, I fear that many won’t even give it a try 
because of the very uninformed press this operating system has 
received.” 

This obviously puts IBM in a difficult position. Even with fight¬ 
ing the wave of prejudice IBM is having some success and new 
end-users are entering the arena. As a result, we at OS/2 Monthly, 
have had many requests for more material focused at the new¬ 
comer to OS/2. We have gone back to the beginning. Bill 
Zinsmeyer alleviates the installation blues for OS/2, in his new col¬ 
umn, which for its introduction is our cover article. 


AND THE WINNER IS... 

The OS/2 Golf T-Shirt goes to Bert Moshier for being the first per¬ 
son to spot OS/2 Monthly in a store. Congratulations Bert! 



Bert Moshier 


Brett Kotch 

• December 1992 






Q&A 


David 

Hunt 


David Hunt is the Manager 
of R&D for a small Midwest 
computer service bureau. 
One of his current duties is 
the supervision of an OS/2 
development group. He is 
anxiously awaiting your 
questions and can be 
reached on CompuServe as 
76326.3641 or by letter care 
of editor at the address in 
the masthead 


I did something a little bit unusual for me a 
couple of weeks ago, I went on a sales call. 
Generally speaking, I couldn’t sell anything to 
save my soul. If I depended on a sales job to 
provide for my family we’d probably be among 
the ranks of the homeless. 

Over the past thirty years I’ve discovered two 
exceptions to that rule. Sometime during my col¬ 
lege years I realized that I could sell things that I 
truly believed in and enjoyed. One of those 
things is bicycles. My most enjoyable college job 
was as a mechanic and sometime salesperson in 
a bike shop. 

I can’t explain the joy that I get just from see¬ 
ing a beautiful bike. And to ride one is almost 
ecstacy. One of the best times I had at the recent 
Windows & OS/2 Conference in Boston was 
when I wandered into a bike shop and spent an 
hour just hanging out. 

The second thing that I discovered I could sell 
during college was cars — not the standard used 
“sleds” that you see littering the ever-present 
“Honest John’s”, or the bland clones that Detroit 
and the Japanese peddle, but truly breathtaking 
true automobiles such as classic sedans or sports 
cars. Unfortunately, most of those automobiles 
have been snatched up by people who have too 
much money and not enough time. Conse¬ 
quently, prices have skyrocketed and the beloved 
beasts sit in garages waiting to be exercised by an 
owner who never appears. I could sell the darn 
things, but I sure can’t afford to buy one. 

So what’s the point? I’ve discovered some¬ 



thing else I can sell — OS/2! A friend of mine 
sells computers in the retail channel. I don’t see 
how any of them make money, but he’s got a 
house, and his family seems to have food and 
clothing. A couple of weeks ago he called to ask 
a favor. One of his old accounts had been turned 
over to another rep at the store and had been 
handled badly. In fact the account (a rather large 
one) was planning to walk. Management fired 
the other rep and gave the account back to my 
friend. He was trying to salvage whatever he 
could from a bad situation when he was asked 
about OS/2. 

At this point my friend had a problem. He 
was trying to reestablish his firm as a knowl¬ 
edgeable vendor, but nobody there knew any¬ 
thing about OS/2. (At this point I could mention 
that I’d been trying to get them to support OS/2 
for a year or so, but that is probably another top¬ 
ic.) So he called me to ask a favor. “Sure” I said, 
“I’d be happy to go on a sales call with you.” It 
was actually fun. 

We visited the network support group for a 
large hospital. My friend had convinced them to 
give his firm one chance to make things right 
and had just sold them six or eight IBM PS/2 
computers. These machines were going to come 
preloaded with OS/2 2.0. What the support folks 
wanted to know was “do we want to keep OS/2 
on these machines, or should we reformat the 
drives and load DOS (and maybe Windows) on 
them?” Having been responsible for supporting a 
medium-sized network at one time, I could un¬ 
derstand where they were coming from. Did it 
make any since for them to accept and support 
one more operating system? 

In talking with them, several things came out. 
Ninety-nine percent of their people were using 
DOS only. A couple of folks around the hospital 
had experimented with Windows (I assume that 
none of them had inhaled.) The only one in the 
whole organization who actually used Windows 
on a regular basis was their boss, and he thought 
DOS and Windows were the way to go. 

I pointed out that I wasn’t there to sell them 
on OS/2. My only role was to answer their ques¬ 
tions about the operating system. I did make it 
clear that I was an OS/2 user and that my job in¬ 
volved the supervision of a fairly ambitious OS/2 
development project. I explained to them that as 
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a result I felt fairly comfortable posing as an 
OS/2 expert. One other noteworthy item, 
just to make the story semi-believable: the 
company my friend works for is loosely 
affiliated with the one I work for, so every¬ 
one was comfortable that I did indeed rep¬ 
resent. some in-house expertise for the re¬ 
tailer. 

The questions came fast and furious. 
How much disk space does OS/2 need? 
How much memory would their worksta¬ 
tions need to run it? Are there applications 
available to run on OS/2? Is OS/2 hard to 
use and support? Would OS/2 run on their 
clones? 

Slowly and surely, I worked through 
their onslaught. To install the entire OS/2 
operating system, I would want at least 
40MB of free space on the drive. This 
would allow for the entire system (full hard¬ 
ware support, online help, applets, etc.) 
and would leave room for an effective swap 
file. I’ve installed OS/2 on 30MB drives 
without much trouble, but I’m not sure I’d 
want to run it on anything less. By the time 
you add comparable functionality to DOS 
or Windows, you are frequently nearing this 
disk volume and the complexity of the con¬ 
figuration will be much worse. 

I mentioned that initially IBM had said 
that systems would need 4MB to run OS/2. 
I’ve run on systems with 4MB and it isn’t 
enjoyable. Even IBM is now saying 6MB is a 
better minimum. Most anybody else you 
talk with is saying 8MB. Memory is cheap 
enough now that I try to get 16MB on all 
the systems I order for my department. I 
don’t have anything less than 12MB, 
though. You just can’t justify giving up the 
performance improvement for the minimal 
dollars that an extra 4MB to 8MB of RAM 
would save you. These memory require¬ 
ments are certainly greater than what DOS 
needs (or can use). Windows will run (I’ve 
been told) on 2MB systems. To get it to run 
well, though, you should consider 6MB to 
8MB. This isn’t much different than OS/2. 

There are OS/2 applications available to 
do just about anything you would want to 
do on a computer. The one caveat is that 
they may not be the ones that you are used 
to using under DOS. On the other hand, 
just about everybody who is anybody has a 
Windows version of their software out now. 
The one thing that OS/2 will do very well 
though (better than Windows) is run your 
current DOS applications. In explaining that 
all of the current DOS applications they are 
supporting could be running (not just ap¬ 


pearing) in windowed sessions on an OS/2 
desktop I hit upon something that was real¬ 
ly worth something to the folks at this hos¬ 
pital. The icing on the cake was when I told 
them that each of these sessions could be 
individually configured. Things like “unlim¬ 
ited” EMS or XMS memory for DOS applica¬ 
tions that are currently causing unbearable 
configuration and support problems on 
their DOS workstations went a long way to¬ 
ward selling the folks in the room that after¬ 
noon. 

We talked about ease-of-use. I men¬ 
tioned an in-house project our group had 
just completed. We wrote an application for 
a group of users in our company who are 
dyed-in-the-wool computerphobes, and 
they love it! The interface is intuitive, easy 
to learn and easy to use in their day-to-day 
work environment. Our in-house support 
team has found that support time has been 
cut. In short, the interface has been a re¬ 
sounding success. 

Would OS/2 run on their clones? This 1 
could answer with absolute certainty, Yes! I 
knew it would because my company had 
bought the same clones that they had in the 
hospital. 

At the end of the meeting they were all 
interested and I invited them to stop by my 
shop for a visit. They were up two days lat¬ 
er with my friend. I demonstrated many of 
the DOS applications they were supporting 
running on my OS/2 desktop. I showed 
them an OS/2 communication program 
downloading messages from CompuServe 
at the same time that I had a DOS commu¬ 
nication program downloading files from a 
BBS through our network modem pool, 
both in the background! My group showed 
them some of the neat “gee-whiz” stuff and 
multi- media gizmos that we play with in 
our development projects. Finally, we went 
to visit the group of computerphobes who 
are using OS/2 in their day-to-day work. At 
the end of the visit the folks from the hospi¬ 
tal (and my friend) were thrilled. 

The next day my friend called. He'd de¬ 
cided to install OS/2 on his computer and 
said that maybe it was something he should 
be using. I’d managed to sell OS/2 to him. 

I haven’t talked to him for a month now 
— we’re both too busy most of the time to 
keep in touch on a regular basis. I think 
that maybe tomorrow. I’ll take a few min¬ 
utes to track him down. I’d like to find out 
what the folks from the hospital have decid¬ 
ed about OS/2. After all, how else can I 
know how good an OS/2 salesman I am?# 
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THE OS/2 2.0 DOS ENVIRONMENT 

PART III 


Less 

Bell 


Les continues his discussion on the DOS 
environment in OS/2 2.0 — Editor 


OS_STARTUP_DRIVE 

See the section on Running Real DOS, below. 
This parameter can be set before starting the 
VDM only, 

DOSJJMB 

If this parameter is set on (the default is off), 
then DOS will manage Upper Memory Blocks in 
the twilight zone and make them available both 
to applications and to the DEVICEHIGH= and 
LOADHIGH statements. Occasionally applica¬ 
tions want to directly access these areas and will 
not run when DOS_UMB is set ON. This parame¬ 
ter can be set before starting the VDM only. 

DOS.VERSION 

The DOS_VERSION setting specifies a list of pro¬ 
grams and the version number which the system 
should report when queried by these programs. 
This allows applications which expect a particu¬ 
lar version of DOS to run, since the DOS emula¬ 
tion simply responds with the appropriate ver¬ 
sion number regardless of what the system 
actually is. This parameter can be set at any time 
before the problem application is run. 

DPMI_DOS_API 

Under OS/2 2.0, an extension to the DPMI speci¬ 
fication, known as DOS API services has been 
implemented. This frees the application from 
having to set up buffers before issuing some 
DOS and BIOS API calls, instead allowing pro¬ 
tected mode applications to use protected mode 
buffers, referenced by protected mode selectors. 
The translation services perform any necessary 
copying of the buffers. 

Applications which are aware of these exten¬ 
sions can turn them on or off if this parameter is 
set to AUTO. Alternatively, it can be set to ON or 
OFF. This parameter can be set before starting 
the VDM only. 

DPMI_MEMORY_LIMIT 

Up to 512 MB of DPMI memory is available in 
each VDM, although the default is 3 MB. This pa¬ 
rameter can be set before starting the VDM only. 


EMS_FRAME_L0CATI0N 

Normally, the EMS page frame is located in a 64K 
block in the VDM’s twilight zone. However, this 
will occasionally clash with a hardware device 
which the application needs to use. If this oc¬ 
curs, the first strategy should be to use the 
EMS_HIGH_OS_MAP_REGION to reduce the ex¬ 
tra address region to zero. If this does not fix the 
problem, then the page frame can be relocated 
to one of the listed addresses. 

A useful technique is to reduce the size of the 
DOS_RMSIZE setting and then locate the page 
frame below 640 KB where it is almost guaran¬ 
teed that no devices can be present to cause 
clashes. 

This parameter can be set before starting the 
VDM only. 

EMS_HIGH_0S_MAP_REGI0N 

This setting is used to increase the size of the 
EMS buffers over the default page frame. It 
should be used in conjunction with the 
MEM_EXCLUDEJREGIONS and MEM_INCLUDE_ 
REGIONS settings. 

This parameter can be set before starting the 
VDM only. 

EMS_L0W_0S_MAP_REGI0N 

Some multitasking environments, e.g. Windows 
and Desqview, can use back-filled memory be¬ 
low 640 KB. This setting enables this feature and 
specifies how much memory is to be regarded as 
back-filled. The default is 384 KB. 

This parameter can be set before starting the 
VDM only. 

EMS_MEMORY_LIMIT 

This setting controls the amount of expanded 
memory available in a VDM. Setting this to zero 
will disable EMS in that VDM; setting it to a huge 
value — e.g. 32 MB — simply wastes memory 
and causes swapping. 

This parameter can be set before starting the 
VDM only. 

HW_N0S0UND 

This setting enables and disables sound output 
from programs. Sometimes sound is degraded by 
the systems timeslicing, at other times multiple 
programs compete for speaker access and all but 
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one should be disabled. This parameter can 
be set at any time. 

HW_R0M_T0_RAM 

This parameter causes the system to copy 
the machine’s ROM BIOS into RAM for 
faster access. This is the same feature as the 
ROM Shadowing provided by some system 
BIOSes. 

This parameter can be set before starting 
the VDM only. 

HW_TIMER 

When this setting is enabled, applications 
can have direct access to the 8253 counter¬ 
timer circuit ports. With it disabled, access 
to the 8253 is virtualized, causing a delay 
between the timer being read and its value 
returned to the VDM so that readings are 
inaccurate. This means that some applica¬ 
tions — for example, games — may run 


unacceptably slowly or may not run at 
all unless allowed direct access to the 
timer. 

Although this setting can be changed at 
any time, it may not work correctly if an ap¬ 
plication programs the timer while it is vir¬ 
tualized and then reads it with direct hard¬ 
ware access. Nonetheless, it can be useful 
to experiment with this setting and observe 
the changes in performance. 

IDLE.SECONDS 

The operating system watches for programs 
performing rapid polling of the keyboard, 
and when it sees this, reduces the priority of 
the application on the assumption that it is 
idling. However, some programs may pause 
briefly to allow user input and then resume 
normal operation, and if the priority has 
been dropped, performance will be degrad¬ 
ed. To override this, this setting disables the 
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Easy to use: 

• Presentation Manager and Workplace 

• Easy access notebook style interface 

• Full on-line help, with hyper-text links 

• Separate on-line documentation 

• Graphical Installation 


Benchmarking Power: 


•32 bit 80386 Code 

• 25 benchmark tests in all 

• Disk drive and diskette drive tests 

• Logging Facility to save and/or print results 

• Computational benchmarks for integer and floating point math 

• Powerful Macro Feature to facilitate test suites, using IBM Rexx 

• 2 high-level benchmarks designed for use in comparing systems 

• 8 video benchmarks that use the OS/2 Graphics Programming Interface (GPI) 


Benchmarks that matter: 

• Designed to access resources and OS/2 system code like OS/2 applications 

• OS/2 Application Tests (requires Excel for OS/2 and/or Describe) 

• Specify your own OS/2, DOS, or even Windows-OS/2 tests 

• Examine the effectiveness of memory cache 


Available for a limited time for )uat $79.95. 

To order call 

(800) 598-1718 In the continental United States or 
(303) 241-1718outa.de the continental United States 

or FAX 

(303) 243-4516 

Shipping and handling charges extra. Visa/Mastercard and 
most P.O.'s welcome. 


SyNErik 

Systems 


2210 Highway 6 & 50. Suite 204 
Grand Junction, CO 81505 


IDLE_SENSITIVITY function for a number of 
seconds after useful work is detected. 

If a program appears to run slowly when 
waiting for user input, this value can be in¬ 
creased. 

IDLE_SENS!TIVITY 

The idle sensitivity is the percentage of the 
maximum possible polling rate above 
which an application is considered to be 
idling. The default is 75% — if an applica¬ 
tion polls more frequently than this, then its 
priority is dropped. However, the applica¬ 
tion may be doing useful work while 
polling the keyboard frequently, and a pri¬ 
ority drop would slow it down unaccept¬ 
ably. If this is the case, this setting should 
be increased. Setting it to 100% turns off 
idle detection completely. 

KBD_ALTHOME_BYPASS 

In the default setting (Off), the Alt-Home 
keyboard combination will switch a DOS 
session between full-screen and windowed 
modes. With it set to ON, this keystroke se¬ 
quence is ignored, and the user must use 
Ctrl-Esc to switch to the session manager 
and then use the DOS sessions context 
menu to switch to windowed mode. This 
parameter can be set at any time. 

KBD_BUFFER_EXTEND 

This parameter increases the size of the 
keyboard type-ahead buffer to the level 
available in OS/2 VIO windows. A few ap¬ 
plications which read raw input will not 
benefit, but few will be adversely affected, 
so the default setting is ON. This parameter 
can be set at any time. 

KBD_CTRL_BYPASS 

This parameter is used to disable either of 
the Ctrl-Esc and Alt-Esc hot-key combina¬ 
tions which switch screen groups or activate 
the Window List, respectively. This allows 
the DOS application to use these key com¬ 
binations for its own purposes. 

KBD_RATE_L0CK 

With this setting turned ON (the default is 
OFF) applications are prevented from alter¬ 
ing the system keyboard repeat rate. 
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An OS/2 Personal Information Management System 
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Workplace Companion Modules: 

• Clock/Calendar 

• Appointment Book 

• Telephone/Address Book 

• Contact Management/To Do List 


Clock/Calendar 

• Analog/Digital Clock 

• Julian/Week/Holidays 

• International Times 

• Custom Alarms 

• Daily Notes 

• Full Year Calendar 

Special 

Introductory Offer: 

$29.95 

Clock/Calendar Module 


The Arcadia Workplace Companion is designed to 
be an integrated part of OS/2 2.0 Workplace Shell 
environment. It is a set of convenient and 
indispensable desktop utilities for every OS/2 2.0 
user. The Companion products are designed 
specifically for OS/2 2.0 from the ground up. The 
user interface follows the Common User Access 
1991 (CUA ’91) guidelines and the conventions 
adopted by the OS/2 2.0 Workplace Shell. More 
importantly, the Arcadia Workplace Companion 
provides the functions you need in an ingenious 


layout. Graphical buttons and value sets represent 
all of the choices that are available. It is so easy to 
use, the on-line documentation is all you will ever 
need. 

For a limited time, the Clock/Calendar module of 
the Arcadia Workplace Companion is available at 
the low promotional price of $29.95. Call Arcadia 
Technologies now for information regarding 
trade-in credit on future modules of the Workplace 
Companion. 



Arcadia 

Technologies 

Inc. 


Tel: (818)446-6945 
Fax: (818) 447-4212 

OS/2, CUA, and IBM are registered trademarks of International Business Machines Corporation. 
Arcadia Workplace Companion is a trademark of Arcadia Technologies, Incorporated. 
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THE OS/2 DOS ENVIRONMENT PART III 


MEM_EXCLUDE_REGIONS 

This setting is used to specify ranges of ad¬ 
dresses in the twilight zone which must be 
excluded from use as EMS pages or XMS 
UMBs because they are used by adapter 
cards such as Super VGAs or network cards. 
This parameter can be set before starting 
the VDM only. 

MEMJNCLUDE.REGIONS 

This setting is used to force inclusion of 
memory ranges in the twilight zone, even 
though the system might suspect that they 
could be used by hardware adapters. If the 
user knows that a DOS VDM session will not 
use a particular hardware adapter, then its 
address range can be marked for inclusion, 
and allocated as EMS pages or EMS UMBs to 
improve performance. This parameter can be 
set before starting the VDM only. 

MOUSE_EXCLUSIVE_ACCESS 

Some applications, such as Microsoft Win¬ 
dows and Flight Simulator, perform their 


own mouse management, and if their mouse 
sensitivity or speed threshold settings are 
different from those of Presentation 
Manager, then the application mouse point¬ 
er and the PM pointer will drift apart, so that 
the user cannot tell the actual position of the 
real mouse pointer. The user can fix this 
problem by turning this setting ON, and 
then clicking either mouse button inside the 
VDM window. This will turn off the PM 
pointer. It can be recovered by pressing Alt, 
Ctrl-Esc or Alt-Esc. 

PRINT_TIMEOUT 

This setting specifies the number of seconds 
between the initiation of printing and the 
closing of the spool file. While the default 
of 15 seconds is fine for screen dumps and 
other small print jobs, more sophisticated 
print jobs and complex print formatting may 
take longer and will therefore be split into 
multiple spool files, producing unaccept¬ 
able print jobs (page breaks in the wrong 
places). The timeout can be set to any 


period between 0 (no timeout) and 3600 
seconds. 

VIDEO_FASTPASTE 

With this setting enabled (default is dis¬ 
abled), the Paste menu option will insert 
text from the clipboard at high speed. This 
can over-run the buffers of applications 
such as the Microsoft Programmers Work¬ 
bench and its precursor, the M editor, and 
other applications which monitor the key¬ 
board interrupts directly. 

VIDE0_M0DE_RESTRICTI0N 

If the user knows that an application will 
always keep an EGA or VGA video card in 
MDA or CGA mode, there is no need for 
base memory to end at 640 KB - it can ex¬ 
tend up to the base of the MDA at B0000H, 
giving an extra 64 KB of user memory, or 
even to the base of the CGA at B8000H, for 
an extra 96 KB of memory. Possible settings 
are NONE, MDA and CGA. If an application 
unexpectedly switches the virtual display 


■% 

Find Code Fast • Change Code Fast 
Learn Code Fast • Port Code Fast 


*3* Sourcelink “for os /2 

SourceLink is an OS/2 programming development tool combining 
the speed and power of hyper-link source code access with a fully 
functional editor. The edit screens are context sensitive. Click to access 
on-line help. Click-click to access your source code. With over 100 
menu items to choose from, SourceLink is packed full of programming 
features. 

Double click on a function, symbol or other string. Let SourceLink 
pop up a list of occurrences. Double click on each occurrence and 
SourceLink will immediately display the source code. Use the integrated 
editor to change or create new code. 

Unmatched in speed and convenience for finding and changing 
source code. Ideal for porting code, changing code, analyzing code, and 
creating programs from existing code, templates and samples. 

SourceLink will save you valuable programming time and energy! 

SourceLink is a refreshing new experience in programming! 

Features: 

• HvperLink source code access. • Context sensitive edit windows. 

• Fully functional editor. • Many file manipulation utilities. 

• Supports ‘C\ C++, MASM. • Find File, Delete, Copy Files/ 

• REXX macro language interface. Directories. 

• Presentation Manager GUI. • Context sensitive View Help. 

• WorkFrame/2 compatible. • Multi-File/Dir. String Search. 

• Generates Function Call Trees. • An OS/2 2.0 32 bit Application. 



SourceLine Software , Inc. 

7770 Regents Rd #/ 13-502 
San Diego, CA 92122 
(619) 587-4713 


Your Satisfaction is Guaranteed 
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LES BELL 


into a high-res graphics mode, this may 
overwrite memory now used by the appli¬ 
cation, so use with some care. This pa¬ 
rameter can be set before starting the 
VDM only. 

VIDEO J)NDEMAND_MEMORY 

With this setting turned ON (default is OFF), 
the system delays allocating a video buffer 
for the worst-case (high-resolution graphics) 
video modes. This means that for many sys¬ 
tems operating in low-memory conditions, 
considerable memory can be saved. How¬ 
ever, if an application switches into a high- 
res graphics mode, allocation of a video 
buffer will be attempted. If there 
is insufficient memory in the system, the 
DOS application will be frozen and unless 
the user is able to reclaim memory by closin- 
g other applications, it may be unrecoverable 
with a risk of lost data. Use with care. 

VIDEO_RETRACE_EMULATION 

With this setting turned OFF (default is ON) 
some applications which show perfor¬ 


mance degradation because of the way 
in which they poll the video retrace port 
will speed up. However, the drawback 
is that screen-switching will not be as reli¬ 
able. 

VIDEO_ROM_EMULATION 

With this option turned ON, the system 
provides a 32-bit emulation of the ROM 
-BIOS INT 10H video functions, rather than 
using the machines ROM BIOS. This is pos¬ 
sible because the VIO subsystem design is 
basically modeled on the INT 10H BIOS 
functions anyway. This will provide a dra¬ 
matic performance boost for applications 
running in a window. However, there is 
a possibility of incompatibility with video 
cards which implement enhanced func¬ 
tionality. 

VIDEO_SWITCH_NOTIFICATION 

When this setting is turned ON (default is 
OFF) applications are notified when they 
are switched to or from full-screen mode. 
This will cause them to redraw their 


screens. However, the OS/2 screen driver 
will usually redraw the screen automatically 
in any case, so re-drawing it again simply 
causes performance degradation. Windows 
2.x and 3.x can utilize this notification, as 
can applications which are written to the 
MS-DOS 3.0 Task Switcher API. This setting 
can be changed at any time. 

VIDE0_WIND0W_REFRESH 

This parameter sets the window update 
rate. Slowing it from the default of 0.1 
seconds can provide more CPU time for the 
application, but making it very slow can 
render the application near-unusable. 
However, this setting affects only normal 
text-type output and does not affect screen 
updates based on keyboard activity or syn¬ 
chronous scrolling operations. 

VIDE0_8514_XGA_I0TRAP 

When this setting is turned ON, the system 
allows the application direct access to the 
8514/A display adapter hardware for faster 
operation. This also eliminates the overhead 
of the 1 MB virtual video buffer. However, 
switching away from the application will 
freeze it, and the system may not be able to 
switch back reliably (unless the application 
responds to the VIDEO_SWITCH_NOTIFI- 
CA-TION callback above). An application 
run in this mode cannot be windowed. This 
parameter can be set before starting the 
VDM only. 

XMS.HANDLES 

This parameter specifies the number of XMS 
handles available for Extended Memory 
Blocks. It should be increased from the de¬ 
fault of 32 only if an application uses a lot 
of XMS handles. This parameter can be set 
before starting the VDM only. 

XMS_MEMORY_LIMIT 

Specifies the global and per-VDM XMS 
memory limits. The default setting is 4 MB 
overall and 1 MB per VDM. This parameter 
can be set before starting the VDM only. 

XMS_MINIMUM_HMA 

This setting specifies the minimum amount 
of memory an application must request be¬ 
fore being granted the HMA (since the HMA 
is not shareable, an application which uses 
only a small part of it is wasting an impor¬ 
tant resource). The default value is zero. 
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THE OS/2 DOS ENVIRONMENT PART III 


This parameter can be set before starting 
the VDM only. 

Virtual Machine Boot 

Although the DOS settings above should al¬ 
low almost all DOS programs to run with at 
most a little tweaking, there will be some 
that pose some problems. For example, a 
few programs depend on DOS data struc¬ 
tures which are not present in the OS/2 
DOS emulation. Some use undocumented 
functions, or features. A particular problem 
for the DOS emulation is programs which 
require a block device driver, since the DOS 
emulation only allows character device dri¬ 
vers to be loaded. 

However, the VDM component of OS/2 
2.0 is able to emulate a complete 8086- 
based PC: processor, display, keyboard, in¬ 
terrupt controller, DMA controller, ROM 
BIOS and other supporting hardware. It is 
therefore possible for the system to create a 
virtual machine which is used to boot gen¬ 
uine DOS in the normal fashion, by loading 
the boot sector of a floppy or hard disk log¬ 
ical drive and allowing the bootstrap 
process to continue. In fact, the virtual ma¬ 
chine can boot any version of DOS, DOS 
clones such as DR-DOS 5.0 and 6.0, other 
operating systems like CP/M and 
Concurrent DOS or even a PS/2 Reference 
Diskette (though the Reference Diskette will 
not be able to change the configuration of 
the real machine, nor should you attempt to 
run diagnostics). 

Multiple VMB sessions can be started, 
with multiple different operating systems 
running simultaneously, a real benefit for 
software developers testing compatibility. 

A VMB is created by copying an existing 
DOS windowed or full-screen session, 
changing the Program title field in its 
Settings Notebook to show that it is a gen¬ 
uine DOS session, and then setting the 
DOS_STARTUP_DRIVE field to reflect the 
location to boot from. Possible settings for 
this field include: 

Startup Drive Meaning A: Boot from the 

floppy in drive A: 

C: Boot from the primary 

DOS partition of drive C: 
C:\BOOTIMG\DOS50.VMB Boot from the 

specified boot image file 


Typically, ones first experiments are done 
using the A: drive. Take an existing DOS 
bootable floppy and try it: a plain vanilla 
DOS boot floppy should come up with no 
trouble at all - the only things to watch out 
for are device drivers for expanded or ex¬ 
tended memory, such as HIMEM.SYS and 
EMM386.EXE, which should be replaced 
with the equivalents supplied as part of 
QS/2 2.0. A similar MOUSE.SYS driver is 
supplied for mouse access. 

However, if VMB will be used regularly, 
the user should install DOS (or multiple ver¬ 
sions of DOS) onto partition(s) on the hard 
disk, using the OS/2 2.0 Boot Manager utili¬ 
ty. DOS must be installed on a primary par¬ 
tition on the first fixed disk, while OS/2 can 
be installed on an extended partition on 
any drive in the machine. 

Of course, this gives rise to another prob¬ 
lem: when booting real DOS, the user 
wants access to extended memory, using 
the DOS 5.0 EMM386.EXE. But under OS/2, 
the user wants to use the stub device driver, 
C:\OS2\MDOS\EMM386.SYS, which calls 
OS/2s memory management services. 
However, there is no need to maintain two 
sets of CONFIG.SYS (or AUTOEXEC.BAT) 
files. Simply list both sets of device drivers 
in the CONFIG.SYS file: DOS ones first, 
then the OS/2 ones. When booted under 
OS/2, the DOS device driver cannot get ac¬ 
cess to extended memory and does not in¬ 
stall, but the OS/2 one succeeds. Under 
DOS, the DOS device drivers load correctly, 
while the OS/2 drivers detect that they are 
not running under OS/2 and do not install. 

Now comes another problem: how can a 
copy of DOS, which understands FAT file 
system only, access an OS/2 HPFS drive? 
For that matter, how can older copies of 
DOS understand the large drives formatted 
by newer versions? 

OS/2 solves this problem by using a 
DOS/OS/2 device driver called FSFIL- 
TER.SYS. This device driver, when loaded, 
acts in a very similar fashion to a network 
re-director. DOS access to a local drive 
which it understands is allowed to proceed 
to the Virtual BIOS and access the disk 
through the virtual machine. However, ac¬ 
cess to HPFS and large drives is trapped 
and redirected through the OS/2 kernel, 
which will return file handles, result codes 


and data just as though a network drive was 
being accessed. This even applies to access 
to genuine network drives, which is redi¬ 
rected to OS/2 and thence to the real net¬ 
work re-director. 

Drive letter allocations can be mapped 
using the FSACCESS.EXE utility, to ensure 
that both DOS and OS/2 sessions see the 
various local and remote drives and parti¬ 
tions in the same way. Judicious use of the 
VOL and LABEL commands helps a lot here. 

Another technique for allowing DOS to 
reside on an HPFS-formatted drive is to cre¬ 
ate a virtual machine boot (VMB) file. First, 
a bootable DOS disk with appropriate de¬ 
vice drivers is created and checked by boot¬ 
ing off drive A:. Then a VMB file is created 
from the floppy with a command such as 

vmdisk a: c:\os2\mdos\dos5\dos5.vmb 

The resultant 1.44MB file contains an im¬ 
age of the boot floppy; if the DOS_START- 
UP_DRIVE of a DOS program reference 
object is set to point to it, it will boot as 
drive A:. As long as the file is not marked 
read-only (desirable in some circumstances) 
you can write to it, edit its CONFIG.SYS file, 
COPY files to it and even run CHKDSK 
on it! 

Using this technique, I have been able to 
teach DOS courses running PC DOS 3 3, 
Compaq MS-DOS 3-31 and MS-DOS 5.0 all 
simultaneously. In fact, if I hadn’t pointed it 
out, attendees would never have realized 
that the copies of DOS were in fact access¬ 
ing an OS/2 HPFS-formatted hard disk! 

A Better DOS Than DOS? 

So, is it a better DOS than DOS? In recent 
months, I have explained and demonstrat¬ 
ed these features of OS/2 to six different 
seminar audiences in the UK and Australia, 
and then asked their opinions. To date, the 
response has been unanimously in favor of 
OS/2, There’s no way I can create a DOS 
5.0 system with over 730,000 bytes of free 
memory. My tests indicate that OS/2 is out¬ 
performing DOS in database benchmarks 
by at least 40%. And under OS/2, I can al¬ 
locate program 32 MB of LIM 4.0 EMS 
memory, 16 MB of XMS and INT15H mem¬ 
ory, and 512 MB of DPMI memory - some¬ 
thing that is going to be difficult with 
DOS!” ♦ 
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DISCOVERING THE 
WORKPLACE SHELL 


Phi- 

phenomenon 

Brett Kotch 


In its early years Gestalt psychology seemed 
revolutionary and aroused much controversy, 
but by mid century it hid ceased to exist as an 
entity all to itself with many of its main lessons 
and factual discoveries being absorbed into the 
mainstream of psychology. 

The founders of Gestalt psychology, Max 
Wertheimer, Kurt Koffka and Wolfgang Kohler 
argued that the nature of the parts is determined 
by, and is secondary to the whole. Such whole 
qualities have always been recognized but their 
explicit experimental study was not fulfilled un¬ 
til Gestalt psychologists began studying the phi- 
phenomenon. With the in-depth analyses of two 
stationary lights blinking in brief succession and 
their impression of movement, Gestalt psychol¬ 
ogy came into prominence. 

Regardless of the impact that Gestalt psychol¬ 
ogy has on our life, there are still some areas of 
science which are just now slowly starting to 
learn a lesson from the Gestalt doctrine. With 
the introduction of the graphical user interface 
(GUI), and the desire to build a better GUI, sys¬ 
tem designers are eager to distinguish their new¬ 
ly formed interfaces from their character based 
predecessors. 


Soft & GUI CommandLine 


File Command Help 


C:\ 


lobject \apps 


Designers must realize that as superb as a 
GUI might be, it will never replace the com¬ 
mand user interface (CUI). Especially now with 
the proliferation of CUI’s available for OS/2, (the 
Hamilton C shell, the Thompson Toolkit and its 
implementation of the Korn shell and the MKS 
toolkit and its implementation of the Kom shell 
along with all of their tools) it would be a 
shame to divorce the two technologies. 

When I organize each month’s issues into the 
various stages of the editorial cycle, it is much 
easier to use the graphical abilities of the WPS 
to get the job done. Links provide a vital role in 
allowing me to represent one article in a direc¬ 
tory labeled by that authors name and in a di¬ 
rectory detailing the state in which it is in the 
editorial cycle, and at the same time, with only 
one copy. By making the folder a work area, I 
can close and open up all of the folders that I 
had been using in my previous session with just 
one click. Although, if I want to inspect a direc¬ 
tory which is not part of my regular agenda, it 
entails finding the drive icon, and profusely 
clicking until I get to the desired folder. The end 
result is a desktop full of windows. 

Some developers have recognized this and 
have begun developing 
programs to bridge this 
_ gap. One is CommandLine. 

J Instead of fondling the 
mouse to get the desired 
folder, its a hot-key away. 
Once you have received 
the CommandLine prompt, 
typing in “lobject” followed 
by the directory you want 
sends a shadow of the 


When the discussion about user interfaces is 
entertained, it usually centers around two 
schools of thought, graphical or chacter-based 
modes. I would like to postulate another possi¬ 
bility, a graphical PLUS character-based mode. 
The combination of the two can yield a far bet¬ 
ter GUI than either one can deliver alone. 


folder to the desktop and opens that folder. 

In the process of writing this article I stum¬ 
bled upon a very powerful integration of the 
CUI and the WPS built right into OS/2, but that’s 
another article. I hope that this trend towards a 
marriage between the GUI and CUI continues. 
Regardless of how advanced the WPS becomes 
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available for Smalltalk/V 
(Win, PM, Mac & 286) 
All Platforms $199.95 
Source Code Included! 


HIERARCHICAL APPLICATIONS LIMITED 

'Working to Make Smalltalk a Better Place to Live” 

(512) 837-2117 or (800) SKY-PAGE Pin 5466843# 

M M Hope; Suite»» Austin, TX M 


INTRODUCING: dBase Read-Only File 
Streams for Smalltalk/V (Win & PM) $49.95 
for Smalltalk-80 Rel 4.0 $149.95 
Source Code Included! 


PHI-PHENOMENON 


or any of its predecessors without an interface to a CUI, we are 
only seeing stationary lights. 

• CommandLine 

Soft & Gui Inc, 

224 East 21st Street 
Brooklyn, New York 11229 
(718) 769-8017 

• The Hamilton C Shell 

Hamilton Laboratories 
13 Old Farm Road 
Wayland, MA 01778-3177 
(508) 358-5715 

• The Thompson Toolkit 

5616 SW Jefferson 
Portland, OR 97221 
(503) 224-1639 

• The MKS Toolkit 

35 King Street North 
Waterloo, Ontario N2J 2W9 
Canada 
(519) 884-2251 
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Tennis Pros, Golf Pros And 
OS/2 PM Programmers 
Have One Thing In Common.., 

.they need proper training and tools to be successful ! 


The right mix makes all the difference! PM programming 
is easier than you think IF you use proper object-oriented 
techniques and high level PM window classes. 

Ask for SE Inter national's 

✓ Inhouse PM programming training. Within one week 
you learn how to succeed in large C and PM projects and 
how to choose the right development tools. 

✓ PM Extensions. Powerful new 16-bit and 32-bit PM 
window classes (FormattedEntryFields, DateEntry- 
Fields, PrimaryWindowClass, Animated Bitmaps...) 
allow you to focus on the application logic and not on pro¬ 
gramming of frequently required window behaviors. All 
our PM Extensions are Gpf™ compatible. 

SE International, Inc. 

621 NW 53rd Street, Boca Raton, FL 33487 
Tel: (407) 241-3428 • Fax: (407) 997-8945 

™Gpf is trademark of Gpf Systems, Inc. 




Saturday, January 01, 


1 
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123.456.789.55 DM! 


SES Software Engineering Services GmbH Berlin 

Koenigsallee 49, D-1000 Berlin 33, Germany 
Tel: +49 30 826 40 63 # Fax: +49 30 825 30 14 
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REVIEW 


• PrntScrn 

• Gpf 


Ron 

Beauchemin 

& 

Paul 

Duncanson 


PrntScrn 

If you have ever had the opportunity to create a 
user manual for software, then you have certain¬ 
ly found the axiom “A picture is worth a thou¬ 
sand words” to be true. 

In the case of a user manual for computer 
products, the pictures are nearly always full or 
partial representations of a computer screen. 
Your first reaction might be that you can simply 
print the screen. However, the Print Screen key 
is an all or nothing proposition — your only 
choice is to get a print of the entire screen. 

In many cases that is inappropriate. For exam¬ 
ple, when there is a need to focus the user’s at¬ 


tention on a dialog box or pop-up information 
box, a print of the entire screen might confuse 
the reader and your instruction would be less ef¬ 
fective. 

Fortunately there is a product that addresses 
the need — PrntScrn by Mitnor Software. It is 
shipped with both the 16 bit and 32 bit versions 
on the same diskette. 

PrntScrn comes with a 52-page manual that is 
very well illustrated and easy to use. The manual 
has two installation sections which address the 
differences between the OS/2 1.x Presentation 
Manager interface and the Workplace Shell inter¬ 
face delivered with OS/2 2.0. Users who are new 
to OS/2 2.0 will appreciate the fact that the install 
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procedure takes them step by step through 
the process of launching the install program 
from the Workplace Shell. 

The installation process determines 
which version of OS/2 is being executed on 
the machine, and based on that determina¬ 
tion, either installs the 16 bit version (OS/2 
1.3) or the 32 bit version (OS/2 2.0). The in¬ 
stallation process is quick and easy. 

Once installed, PrntScrn can be invoked 
by placing it in the startup folder or by dou¬ 
ble clicking on it’s icon in the same manner 
as you would for any other application. 
Once this is done, PrntScrn is ready for use. 
The user can change the various options of 
PrntScrn at any time by selecting it from the 
OS/2 task list or by double-clicking on the 
minimized icon. PrntScrn provides the capa¬ 
bility to capture the entire screen, the cur¬ 
rent active window, the client area of the 
current active window, a selected window, 
the client area of a selected window or any 
specified rectangular area. 

PrntScrn provides a color mapping facili¬ 
ty that allows you to map the captured 
screen area to a sixteen color image, an 
eight color image, a non-dithered black and 
white image or a dithered black and white 
image. In addition to the color mapping, a 
printer scaling feature is provided. The scal¬ 
ing affects only the printed image which 
means that images saved to disk are un¬ 
sealed. This is important because it allows 
you to scale up an image to multiple sizes 
without having to capture it again. The scal¬ 
ing feature uses integer scaling. This means 
that the scaling must be in whole-number 
multiples of the original size. The scalings 
provided are double size, triple size, 
quadruple size and maximum integer size. 
Maximum integer size is actually an auto¬ 
matic print-to-fit function that selects the 
largest integer size multiple that will allow 
the captured image to be printed on the 
current size form. 

PrntScrn can also save the captured area 
to disk in one of ten formats. The formats 
are WordPerfect graphics, Presentation 
Manager 1.2 bitmap, Presentation Manager 
2.0 bitmap, Presentation Manager Metafile, 
PC PaintBrush, TIFF, TIFF compressed, TIFF 
Grayscale, CompuServe GIFF and Windows 
bitmap. 

The PrntScrn capture function is initiated 
by pressing the Print Screen key. The dispo¬ 
sition of the captured area is determined by 


the current parameter settings within 
PrntScrn. 

PrntScrn as has an import facility that al¬ 
lows the user to import Presentation 
Manager 1.2 and 2.0 bitmap files, Windows 
bitmap files, Presentation Manager Metafiles 
and text files into the clipboard. Once a file 
has been imported, it may be pasted to the 
clipboard and saved in any of the ten file 
.formats mentioned earlier. I tested this fea¬ 
ture by importing a text file, the OS/2 2.0 
logo bitmap and the Windows bitmap 
FROG.BMP that was distributed by Micro¬ 
soft on the Windows 3.1 Developer Kit 
CDROM. I encountered a small problem im¬ 
porting the Windows bitmap from the 
CDROM. PrntScrn encountered an access 
error. I reported the problem to Mitnor and 
they are fixing it. Once I used the OS/2 
copy command to copy the Windows 
bitmap from the CDROM to the hard disk, 
everything worked fine. Although not 
specifically mentioned in the documenta¬ 
tion, PrntScrn can be used as a conversion 
utility to convert any of the import formats 
to any of the output formats. 

A moveable date/time window and a 
screen blanker are built into the product. 
These features are user selectable at any 
time. The screen blanker will blank 
Presentation Manager and OS/2 full-screen 
or OS/2 windowed sessions. The blanker 
has no effect on full-screen VDM applica¬ 
tions. 

The authors thought about customer 
support when they designed the product. 
They built in a debugging capability that 
can easily be invoked by the user. This fea¬ 
ture can be used to help Mitnor Software 
technical support personnel quickly resolve 
user problems should they occur. 

I have run PrntScrn under OS/2 2.0 both 
on a stand-alone PC and on a PC connected 
to a Novell 3.11 token-ring network. The 
network workstation uses the OS/2 2.0 
Novell Requester and utilizes a LaserJet 
printer attached to the network. The prod¬ 
uct worked fine in both environments. The 
product can also be loaded on the network 
server and run as a server application, but I 
did not test it in that mode. 

There were no noticeable performance 
impacts while running PrntScrn along with 
other applications. Utilizing CPU Monitor 
from Bon Ami Software (which will be re¬ 
viewed in a later article) I was able to deter¬ 


mine that PrntScrn utilized 7% of the CPU 
on a Northgate 386 33 MHz machine. The 
7% figure is a worst-case scenario. The 7% 
level was reached while PrntScrn was writ¬ 
ing the screen image to disk. The file was 
written to disk very quickly and the CPU 
utilization for PrntScrn dropped to zero. 
PrntScrn provides the user with an audible 
beep to signify that the capture operation is 
complete. As a final test, I invoked PrntScrn 
while a CD-ROM audio track was playing in 
a Virtual Boot VDM. As expected with OS/2 
2.0 there was no impact whatsoever on the 
CD-ROM application. 

I would recommend this product to any¬ 
one who prepares documentation, user 
manuals or procedures for Windows or OS/2 
applications running under OS/2. — RB 

Editor's note 

For those of you who would like to see a 
sample of this product before you consider 
purchasing it, OS/2 Monthly has used 
PrntScrn exclusively since the last issue. 

PrntScrn is produced by Mitnor Software 
and is priced at $115. Mitnor Software 
can be contacted at 918-357-1628. The 
FAX number is 918-585-3303- 


Gpf 

Case tools have long been a good idea 
whose reality has never quite lived up to 
the promise. They have always taken a long 
time to learn and have had limited utility. 
The 4GL’s I’ve tried always seem to run out 
of gas just when I need them the most, forc¬ 
ing me to revert back to C and just about 
start over! They’re OK for prototyping but 
lack the capability of producing a “World 
Class Application.” 

Much (for some applications, even 
MOST) of the work of writing a PM 
(Presentation Manager) Application or any 
GUI (Graphical User Interface) is producing 
the GUI itself. I’ve seen OS/2 PM applica¬ 
tions where the percentage of code to cre¬ 
ate the GUI portion of the application var¬ 
ied from 5% to 95% of the total code. Add 
to this the complexity of creating the hyper¬ 
text help data (in an IPF file format) and 
making Resource files to reference text 
strings, icons, and other resources. Also add 
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Do You Really 
Think We'd Let You 
Go To Management 
To Get Money For 
An Object DBMS 
Without Giving You 
Ammunition 
About Why It 
Makes Brilliant 
Financial Sense? 


Tell your management to forget all this nonsense about how the production reality of object 
database management systems is still years away. Tell them that ONTOS already has some 400 
customers worldwide. 

Let them know that some of the most widely respected leaders in communications, manufacturing, 
financial services, health care, and government are experiencing dramatic productivity gains and 
increased competitiveness—this very day—thanks to the inherent benefits of the ONTOS DB. 

For a copy of our brochure. The Impact of ONTOS, phone 1-800-388-7110, Ext. 207. And when 
management asks you what the ONTOS Object DBMS is going to do for the enterprise, tell them.. .well, 
tell them to fire up their calculators. 


»NT( )S 


© 1992, ONTOS, Inc., Three Burlington Woods, Burlington, MA 01803. All rights reserved. 
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OS/2 2.0 

printing 
as simple as... 

1 . 2 . 3 . 

Font Cards Font Cartridges Soft Fonts 

for IBM/Lexmark for Hewlett-Packard in tape or diskette for 
LaserPrinters Laser Printers various laser printers 

512.490.2240 


Architext has a library of over 10,000 fonts, also available are custom fonts and font 
modifications . Font formats include Bitmap, PostScript, TrueType, and Intellifont. 
ATM compatible. With Architext you have the freedom to create your font card or 
cartridge suited to your needs. Choose from fonts, bar codes, logos, and/or signatures 
A Graphic Artist will work with you in choosing the fonts and graphics to fulfill your 
printing specifications. Let us help you make printing easy and affordable. 

^ Architext 

121 Interpark Blvd Ste 208 San Antonio, TX 78216-1808 512.490.2240 Fax 512.490.2242 
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that most business applications must refer¬ 
ence a data base and that means SQL 
(Structured Query Language) mixed with C 
in a SQC file. A good OS/2 PM programmer 
is not going to be produced overnight. 
Learning the basics will take six months or 
more on one's own. 

Developing a 32 bit OS/2 PM app means 
using the IBM C Set/2 and the IBM Workset. 
As good as the IBM Workset is, and even 
with 8.5 megabytes of excellent sample 
code, not everything is covered. The next 
hurdle facing OS/2 is to produce enough 
quality applications to show the superiority 
of applications that fully utilize the features 
of the operating system. But, with a steep 
learning curve and a real shortage of quali¬ 
fied OS/2 v2.0 PM programmers, how will 
this demand be met? 

The answer is Gpf (GUI Programming 
Facility) from Gpf System, Inc. My first 
close-up look at Gpf was in May of 1991 at 
the first of the IBM OS/2 v2.0 Technical 
Seminars in Texas. It looked really 
promising, but with a $3600 price tag and 
only a 16 bit version for OS/2 1.x, I decided 
to wait. As I have said, I’ve bought things 
that look good in the past only to be disap¬ 
pointed and be out the money too. Well, 
Gpf has lowered the price to $995.00, 
added features, and recently released a 
OS/2 v2.0 32 bit version that not only does 
it all, but does it all amazingly well. Anyone 
doing serious OS/2 v2.0 PM simply must 
buy this product. It will save it’s entire cost 
in the first week! 

The value of Gpf is 3 fold: 

1. As a programmer training tool. 

2. As a rapid prototyping tool. 

3. As a GUI visual programming tool or 
GUI screen painter to automate the produc¬ 
tion of C, IFP, Resource, and SQC files. 

The first step in using Gpf in any of the 
three ways is to invoke Gpf and load an 
existing project in development or to in¬ 
voke the menu to define a new project. 
You simply give the project a name, 
choose a copyright message and compiler, 
and indicate whether or not you will be us¬ 
ing the OS/2 Database Manager. Then, you 
start opening windows and dialog boxes 
and placing controls in them. The objects 
menu item of the Gpf editor lets you select 
and define the characteristics of Message 


Box, Presentation, Icon/Bitmap/Pointer, 
User Function, and User Control objects. A 
presentation object, for instance, would let 
you define a font style, size, foreground 
and background color as a building block. 
The create menu item of the Gpf editor lets 
you select a Window, Dialog Box, Menu, 
and all the standard as well as the custom 
controls. If you select a “Slider” control, 
you can place it in a window where you 
want and size it. A full screen options win¬ 
dow then opens up with check boxes, ra¬ 
dio buttons, edit fields, etc. that enumerate 
all the possible variations and options 
available in PM for that control. You can 
also go to an “Actions” window to select 
many standard actions to be associated 
with that control. For various types of win¬ 
dows and control, these actions can be as 
simple as setting the focus, or as complex 
as querying the database and placing items 
from it in a MLE (Multi Line Edit field). An 
even more complex action require you to 
write your own C code to implement the 
algorithm. 

As a programmer training tool, it pro¬ 
duces a quality, well-commented C code, as 
well as an SQC, IPF, definition, resource, 
and C header files. The OS/2 PM paradigm 
is so rich that even an experienced PM pro¬ 
grammer may forget how to implement 
some features. It may be quicker to simply 
draw the GUI features with Gpf and let Gpf 
generate the source files. New programmers 
can get tremendous training benefits by ex¬ 
amining and studying the Gpf-produced 
source file. 

As a rapid prototyping tool, Gpf has an 
“Animate” mode and a “Test” mode for 
checking the look and feel of the GUI inter¬ 
face you’ve drawn before any source code 
is generated. The Test mode is the simpler 
of the two, allowing only simple selection 
of value sets, containers or push-button, etc. 
The Animate mode allows such complex 
actions as the display of list boxes that actu¬ 
ally contain data from your SQL database. 

Once you have your applications PM in¬ 
terface prototyped approximately as you 
want it, you can let Gpf generate the source 
files. Here, you are using Gpf as a visual 
programming tool. This is as simple as se¬ 
lecting GENERATE from the TOOLKIT 
menu bar item of Gpf. Gpf generates all the 
different files required to generate the GUI 
portions of your program. It also generates 


the shell code for the algorithm portions of 
the program. You, of course, must generate 
the source code to actually implement the 
algorithm portion. 

Gpf allows three basic techniques for 
merging your own code to the Gpf pro¬ 
duced code. 

1. Directly modify the Gpf generated 
source code; 

2. Create a user control object; 

3. Create a user function object. 

The problem with directly modifying the 
Gpf-generated source code is that\if you de¬ 
cide to revise any aspect of the GUI inter¬ 
face using Gpf, all your modifications to the 
code will be lost when you generate the 
source files again. 

You can create you own controls and 
use them as standard program-building 
blocks. If you have a need for a circular 
gauge type control, you can create one and 
use it as a standard building block just like 
the sliders and push-button controls. 

The creation of user function objects is 
the best way to merge the algorithm por¬ 
tions of your code, so that you can revise 
the GUI with Gpf and still not lose your ad¬ 
ditions. By selecting USER FUNCTION OB¬ 
JECT from the OBJECTS entry on the Gpf 
menu bar, you can add a new user function 
object. You give your new user function 
object a name and add up to four k of C 
language source code to the resulting edit 
box for inclusion into the Gpf-generated 
code. Generally, you will add only one line 
— a function call to a function that will en¬ 
capsulate that portion of your algorithm 
code. Gpf knows to look for a header (.h) 
file with the same base name as your appli¬ 
cation for the prototype of the function. 
The function code itself can be compiled 
and placed in a library or DLL (Dynamic 
Link Library). 

As a final step, you can invoke your PM 
compiler to compile and link your new pro¬ 
gram. Then, execute the resulting EXE file 
directly or via your debugger to debug the 
algorithm portion of your code. It is amaz¬ 
ing how fast you can produce a PM appli¬ 
cation with Gpf. At the end of only a 
two-hour Gpf session, I’ve generated appli¬ 
cations in which the C source file alone was 
over 225k. How long would it take you to 
write 225k of C source? As much as the C 
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source code generation time is cut, the de¬ 
bug time is cut even more. Since the GUI 
portion and the shell code for the algorithm 
are produced by Gpf bug-free, you can 
concentrate on the bugs you introduced in 
the algorithm portion you added. Unlike 
many 4GL’s, there are no per-copy royalties 
on programs you produce with Gpf. 

As you can tell, I am very impressed 
with this product and plan to make it part 
of my standard toolkit. There are only a 
couple of minor negatives. The worst is that 
the tutorial needs some major revisions. It 
took me several tries to get through it. To 
make sure it was not just due to my own er¬ 
ror, 1 asked three other OS/2 PM program¬ 
mers to try the tutorial. Two of the three re¬ 
quired help from me get through it. When I 
first tried the tutorial I had to call the Gpf 
Systems help line. The good news is that 
the help line person was extremely knowl¬ 
edgeable and quickly got me back on track. 
Once you have completed the three tutorial 
exercises, you’ll be well on your way to be¬ 
ing competent in using Gpf. Even if you 
stop to analyze what you have done, and 
take time out for a phone call or two to the 
help line, you can do this in less than a day. 
The second negative is that a better control 
copy needs to be incorporated into the 
product. For instance, I created a text value 
set of the months of the year in two rows of 
6 columns each. In the same dialog box, I 
needed to repeat this value set to get a dif¬ 
ferent month. While I could copy the value 
set as a text value set with two rows of 6 
columns each, I had to enter the names of 
the months again via the Gpf menus. While 
there are ways around this, including a util¬ 
ity on the Gpf BBS, a better copy needs to 
be integrated into the base system. But, 
even with a couple of minor negatives, it’s 
hard not to love a tool that lets you do in 
two days, what used to take a month! Gpf is 
a must-have for any serious OS/2 PM devel¬ 
oper. — PD 


A free demo version of Gpf is avail¬ 
able upon request from the company. 
Gpf, cn be ordered from Gpf Systems 
Inc., P.O. Box 414, 30 Falls, Rd., Moodus, 
CT 06469. Phone (203) 873-3300 or (800) 
831-0017. Fax is (203) 873-3302. 
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GammaTech 

Utilities for OS/2 

Get the Best Performance and Reliability From 
Your Mission Critical OS/2 Work Station 

The GammaTech Utilities are designed to 
enhance and complement your OS/2 system. 
Several utility functions are implemented in a 
Presentation Manager shell while others are 
provided in a command line mode for quick and 
easy access. These utilities provide the ability 
to perform the following maintenance and 
recovery operations easily without extensive 
technical knowledge: 

Easy Graphical Installation 

SAA CUA Compliant PM Interface 

Optimize HPFS Volumes 

MS LAN Manager Support 

Recover Erased Files 

Obliterate Sensitive Data 

Mass Erase Selected Files 

Display Volume Information 

Alter File Attributes 

Add Comments to Files 

Alter File Time Stamps 

Locate Files 

Edit Disk Sectors 

Test Disk Media 

Display File Fragmentation 

Display Directory Information 

Supports HPFS386 

Supports Long File Names 

Supports Extended Attributes 

The Best Time to Acquire Recovery Software 
is Before you Need it. 


For OS/2 version 2.0 or 1.3. 


List $125.00 


VISA, MasterCard, COD, Purchase Orders 
Federal Express Shipping for Fast Delivery 


Post Office Box 70 
Phone (405) 359-1219 



Edmond, OK 73083 
FAX (405) 359-7391 
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ON THE EVE OF INSTALLATION 

BEGINNER'S SLOPE 


Welcome to the Beginner’s Slope! Since this is a column for OS/2 
v2.0 novices and newcomers, a logical topic for the first column 
is how to prepare for installation. With this, as with future topics, 
there won’t be much discussion of the bits and bytes that make 
OS/2 tick; the excellent columnists in other sections of this 
magazine can provide that. Here we’ll take a more pragmatic ap¬ 
proach to utilizing OS/2 quickly and enjoyably, and just a small 
amount of DOS knowledge on the part of the reader will be as¬ 
sumed. 

The subject of this article was not chosen because installation 
of OS/2 is difficult. Contrary to what you may have heard, it’s ac¬ 
tually quite easy, takes about 50 minutes and usually goes without 
a hitch. But there are many ways in which to in¬ 
stall OS/2, so this article will attempt to guide 
you through the decisions to be made. And be¬ 
cause installing a new operating system is a big 
step that involves some risk no matter how sta¬ 
ble and friendly the operating system is, this ar¬ 
ticle will remind you to take a few sensible pre¬ 
cautions as well. 

Many of the following steps are recommend¬ 
ed not just before installing a new OS, but 
whenever making a major change in your sys¬ 
tem’s configuration, and some should be per¬ 
formed on a regular basis. The steps are: back¬ 
up all files, make certain your hardware is 
appropriate for OS/2, decide on which final 
configuration is desired, create a bootable DOS 
floppy if one is not already available and, if you 
will be changing the hard drive partitions, prac¬ 
tice repartitioning the hard drive under DOS us¬ 
ing the FDISK command. If the machine is or 
will be attached to a LAN, make a record of all 
network addresses in case they are needed after 
installation, and be certain the proper LAN re¬ 
quester is available for the PC to access it under OS/2. In a similar 
vein, record all frequently used telecommunications information. 

The most important of the steps above is backup. Backup is 
listed even before evaluation of hardware because it never hurts 
to do an extra backup. Perhaps a warning to backup doesn’t be¬ 
long in a column aimed at beginners, because it often seems that 
only experienced computer professionals forget to backup (!). But 
seriously, to backup frequently is sound computing practice and 
this includes taking backups of all the original diskettes that come 
with your various software packages. 

If OS/2 is being installed “in place”, that is to say, over DOS or 
on top of an older version of OS/2, then the main purpose of back¬ 


ups is to restore the system to its original state if a problem arises 
during installation. However, if OS/2 is going onto a recently repar¬ 
titioned or otherwise empty hard drive, then backups are frequently 
used to place previously existing applications and data back on the 
hard drive after OS/2 has been installed. As much as possible, try to 
avoid using backups to place files back on the disk, especially if 
data compression packages such as Fastback or Central Point 
Backup are being used. Reinstalling applications from the original 
diskettes is preferable to using backed up data for two reasons: first, 
a package that is installed on one drive often will not work when 
restored to a different drive, and second, if DOS backup/compres- 
sion packages are used, there’s a good chance the software will not 
be compatible with OS/2 v2.0. Even if your sys¬ 
tem has a large hard drive, has many files and the 
original disks for the applications are not avail¬ 
able, it’s best to forget about using any of the 
commercially marketed DOS backup packages. 

If you’re experienced with PCs and are not 
daunted by the challenge, you can experiment 
with Fastback or one of the other packages, but 
don’t stake any vital data on the outcome. In 
any case, there are easier ways to save your 
data for use later under OS/2: probably the best 
approach is to use the BACKUP command that 
comes with DOS. This won’t provide the op¬ 
tions, flexibility and high compression ratios of 
some of the “name” packages, but there’s no 
concern about compatibility. The complemen¬ 
tary command to be used under OS/2 is RE¬ 
STORE, and it will restore files even to HPFS 
format (more on HPFS later). Don’t waste time 
looking for it in a DOS window however; RE¬ 
STORE is requested from an OS/2 command 
prompt. 

An alternative approach, if you’re fortunate 
enough to be attached to a LAN, is to reserve some space on the 
server to temporarily hold data during repartitioning and installa¬ 
tion. If there’s enough room, no compression will be necessary 
and the simple command XCOPY will suffice. If the server is not 
quite that generous, then use BACKUP. Even the utility PKZIP 
might provide all the compression that’s needed to backup data to 
the LAN server. On the OS/2 side PKZIP2 and PKUNZIP2 usually 
come installed with the system (that’s right; “usually”). When 
restoring is done and everything is working, remember to delete 
the data from the server so that other people can use the space 
while installing OS/2. Of course, none of this applies if the hard 
drive will not be repartitioned or reformatted. 



Bill Zinsmeyer 
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Now that all the files have been careful¬ 
ly backed up, the hardware can be evaluat¬ 
ed. The requirements of OS/2 are well 
known: at least 4Mb of RAM, a 386SX or 
better processor, about 40Mb on the hard 
drive and a mouse or other pointing de¬ 
vice. It’s also fairly well known that run¬ 
ning OS/2 on a system with just these min¬ 
imum requirements is not much fun. A 
configuration more likely to provide enjoy¬ 
able performance would have 8Mb of RAM, 
a 386DX-25 processor and 80Mb on the 
hard drive. When estimating available 
space, keep in mind the possibility of delet¬ 
ing DOS, any memory manager and 
Windows (although not everyone will feel 
ready to do this). If you are installing 
Extended Services or LAN Services as well, 
then additional space should be kept avail¬ 
able. If you are considering an improve¬ 
ment to your system in preparation for 
OS/2, note that as a general rule additional 
memory will be a greater boon to OS/2 
performance than a faster CPU. After the 
CPU, consider improving disk speed and 
disk space for better performance. 

Assessing the hardware 

When assessing the hardware, remember 
also that OS/2 is one of the greatest tests of 
components ever invented. This means, for 
example, that if the CPU is an early version 
containing a mask error, the first time you 
find out about the problem may be when 
you start to use OS/2 (just as in software, 
bugs occur in CPUs). Similarly, if the RAM 
consists of inexpensive chips from a disrep¬ 
utable manufacturer or if the printer cable 
does not have all of the connections func¬ 
tioning that it should, OS/2 might be the 
first to detect that something’s amiss. 
Sometimes DOS and Windows will not re¬ 
veal these problems, thus giving the illu¬ 
sion that all is well. OS/2 is probably the 
first software you’ll own that will utilize the 
components of your system to their maxi¬ 
mum potential, so, unfortunately, it might 
also be the bearer of bad tidings. 

Attention must also be paid to video 
adapters and SCSI drives. Certain video 
cards such as Tseng-based cards do not yet 
work well with OS/2. With some chips (the 
“S3” chip, it has been said) erratic behavior 
can result during mode-switching. Mode¬ 
switching is a reference to the switch into 
Super VGA mode for Windows under OS/2 


and the subsequent switch back to VGA for 
OS/2. This is why a few critics claim OS/2 
does not provide “seamless” Windows — 
because there are still some difficulties with 
SVGA. Just be patient and live with VGA a 
little longer; these problems are being 
solved quite rapidly, so the critics will soon 
have to look for some other minor point to 
harp on. Check with IBM or your video 
card manufacturer if you are concerned. 

Other peripheral devices 

Other peripheral devices that are somewhat 
out of the ordinary, such as scanners, tape 
drives and CD-ROM drives, can pose a bit 
of a challenge under OS/2, although many 
work with no trouble. Certainly caution 
must be exercised when planning to use a 
SCSI drive with OS/2, because SCSI device 
drivers (the software necessary for the de¬ 
vice to interface with the operating system) 
are not plentiful at this point. Availability is 
increasing every day, however, so check 
with IBM or with the manufacturer. As for 
other peripherals, it’s important to note that 
if no device driver has been written for 
OS/2 v2.0, it does not mean that the device 
cannot function under OS/2. In almost 
every case, the existing device driver can 
be defined to any or all VDMs, so the scan¬ 
ner or other device is available within OS/2 
through DOS sessions at least. (VDM stands 
for Virtual DOS Machine, or a DOS box to 
us novices.) 

The more unconventional the peripher¬ 
als, the more likely you’ll want to keep na¬ 
tive DOS available in your filial system con¬ 
figuration. Even an innocuous piece of 
software such as the educational games 
produced by Walt Disney can be reason 
enough to keep standard DOS in some 
form. Because the Disney software “talks” 
through a speaker attached to the printer 
port and because OS/2 takes much firmer 
control of printer output than DOS or 
Windows (and also because the interrupt 
rate for OS/2-DOS is less than native DOS) 
the sound quality is unacceptable under 
OS/2. This is not a shortcoming of OS/2: 
sending sound through the parallel port is 
a little strange anyway. Also, it’s great that 
OS/2 has a sophisticated print spooling fea¬ 
ture and, besides, the software in question 
has poor sound quality under Windows as 
well. Believe it or not, IBM, among all their 
other tasks, is working on getting the 


Disney software to sound clear under OS/2. 
To summarize then, there are a few valid 
reasons why the version of DOS provided 
within OS/2 might not be sufficient, such as 
having unusual peripheral devices or not 
wanting to explain interrupt rates to an un¬ 
happy 3-year-old. 

A purely OS/2 setup is recommended if 
it’s practical, but if not, then the decision 
must be made which approach to use: Dual 
Boot or Multiple Boot. Dual Boot allows 
DOS and OS/2 to coexist in the C partition. 
Only one system may be active at any one 
time. Dual Boot, if installed over the exist¬ 
ing DOS, has the advantage of avoiding all 
the time-consuming tasks involved with 
repartitioning and reinstalling a lot of soft¬ 
ware. A complete backup is still recom¬ 
mended, of course. Installing Dual Boot 
without any reformat and the associated re¬ 
placement of data is only practical if the 
existing C partition is large enough. 

Multiple Boot was originally intended to 
permit the installation of more than two 
operating systems (AIX could be the third, 
for example) but it works very well with 
just DOS and OS/2. Some people feel more 
comfortable keeping the two systems dis¬ 
tinctly separate. Multiple Boot requires the 
installation of Boot Manager, which occu¬ 
pies 1Mb on the hard drive, and it takes 
advantage of the fact that OS/2 v2.0, unlike 
DOS, does not have to reside in the pri¬ 
mary partition; it runs just as well from an 
extended partition. Here is a typical 
arrangement for Multiple Boot on a 120Mb 
hard drive: 1Mb for Boot Manager (as¬ 
signed no letter), 4Mb for DOS (drive C), 
63Mb for OS/2 with HPFS (drive D), and 
the remaining 30Mb formatted as FAT for 
DOS and OS/2 to share (not simultaneous¬ 
ly) in drive E. 

Other considerations 

Although Dual Boot, Multiple Boot, Boot 
Manager and several sample configurations 
are described quite well in the Installation 
Manual, a couple of further points should 
be made. One important point: if new par¬ 
titions are created using the FDISK feature 
of OS/2, DOS FDISK will be unable to re¬ 
move those partitions. This only becomes 
an issue if installation has to be halted and 
abandoned for some reason, in which case 
the OS/2 FDISK function available on the 
first two or three installation disks must be 
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ON THE EVE OF INSTALLATION 


invoked again to remove the partitions. 
Also, it is recommended that one have at 
least a basic understanding of primary, ex¬ 
tended and logical drives, which are divid¬ 
ed into C, D, E and so on. 

More advanced users 

For more advanced users, another variation 
that makes clever use of the Multiple Boot 
option is to reserve a partition for another 
copy of OS/2. This would not squander 
much space on the drive (only 4Mb) be¬ 
cause it would be a greatly reduced copy 
of the operating system, lacking the graphi¬ 
cal Workplace Shell. This is, in effect, an al¬ 
ternative to keeping a bootable OS/2 
diskette on hand and, as stated, is an op¬ 
tion more of interest to experienced users 
than to novices. The partition could include 
more files than would fit on a bootable 
floppy and so have greater functionality. 
For more information about OS/2 on a 
bootable diskette there are help documents 
available on CompuServe, on other elec¬ 
tronic bulletin boards and from IBM. 

Many hard drives will not need to be 


repartitioned, but many will still have parti¬ 
tions of 32Mb or smaller which are 
holdovers from earlier versions of DOS. A 
common question asked when planning to 
install OS/2 is whether the “lower” drives C 
and D can be merged together and refor¬ 
matted, or have their proportions relative to 
one another shifted, while leaving the 
“higher” drives E and F undisturbed. 
Perhaps this could be accomplished using 
some specially written utility to cleverly al¬ 
ter the file allocation tables, but for most 
people it is not practical. The DOS FDISK 
command will refuse to cooperate if asked 
to delete a lower drive while an extended 
drive still exists above it. In any case the 
data on C and D would be lost. 

It’s conceivable, with the right starting 
configuration, that the Multiple Boot option 
could be installed by merging and refor¬ 
matting the higher drives, leaving DOS and 
other files in the lower drives undisturbed. 
The process would require some proficien¬ 
cy with PCs, however, and should only be 
tried on an experimental basis. It might 
work because Boot Manager does not need 


to be installed at the beginning of the hard 
drive; it can also be installed at the very 
end. 

Another major decision to be made with 
regard to installation is whether or not to 
utilize the High Performance File System 
(“HPFS”). The conventional DOS file sys¬ 
tem, which can still be used for OS/2, is 
called “FAT” for File Allocation Table. FAT 
was originally created as a hybrid of the file 
systems found in UNIX and CP/M, and al¬ 
though it has been greatly improved since 
its creation, it still retains some disadvan¬ 
tages from its relatively old heritage. 

Main advantage of HPFS 

The main advantage of HPFS is speed. The 
FAT system still looks for files sequentially, 
which can degrade access time in a large 
partition. HPFS uses a search algorithm and 
other enhancements to improve access 
time. FAT file names are still limited to the 
eight-dot-three pattern, while HPFS allows 
names up to 254 characters in length and 
permits greater use of special characters, 
including spaces. The FAT system is prone 
to file fragmentation and lost chain prob¬ 
lems which utilities such as Norton or PC 
Tools are often used to remedy. HPFS 
greatly reduces these problems so that 
clean-up utilities are not necessary. HPFS 
maintains not just the data contents of a file 
but also the extended attributes associated 
with it (as does FAT under OS/2). Extended 
attributes can hold the name of the person 
who created the file, the creation date and 
time, the icon used to represent the file 
graphically, any executable-program-to- 
data-file association that’s been established 
and other information. 

Extended attributes provide many useful 
and interesting benefits that could be the 
subject of an entire article, but they won’t 
be discussed here as they are supported by 
both file systems in OS/2 and therefore do 
not affect the HPFS vs. FAT decision. In 
fact, FAT under OS/2 has been improved in 
several respects (lazy writing and caching, 
to name two), but HPFS is the better choice 
for large hard drives. It’s interesting to note, 
by the way, that OS/2 was designed to 
adapt easily to new file systems in anticipa¬ 
tion of the day when a better one is invent¬ 
ed. 

If HPFS is clearly superior to FAT, and it 
is, one might wonder why consider using 
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programming by the book. 
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Fax: 319-362-3701 



24 



OS/2 Monthly • December 















BILL ZINSMEYER 


FAT at all under OS/2. HPFS does have 
some small disadvantages, the principal 
one being that if DOS is booted up inde¬ 
pendent of OS/2, all partitions formatted 
for HPFS will be inaccessible to DOS. The 
HPFS partition can seem “invisible” so that 
DOS, with certain configurations, will tem¬ 
porarily remap the higher drive assign¬ 
ments while it is active, thereby confusing 
software applications (and the user). If na¬ 
tive DOS is used frequently it is convenient 
to be able to access files in all partitions. 
On those rare occasions when OS/2 has a 
problem it’s often very helpful to attempt a 
fix from DOS, which HPFS can prevent. 

The High Performance File System is not 
recommended on a system outfitted with 
less than 8Mb of RAM. HPFS ties up about 
0.5Mb of RAM and also occupies slightly 
more disk space than FAT, at least initially. 
Also most DOS and Windows programs, as 
well as some older OS/2 programs, cannot 
accept long file names, although this is 
only an inconvenience and not a genuine 
reason to avoid HPFS. Long names are op¬ 


tional, so simply stick to the eight-dot-three 
convention,while using DOS and Windows 
programs, and they will work well under 
HPFS (and often run faster). It is commonly 
asked whether diskettes can be formatted 
to use HPFS. They cannot, and when files 
with long file names are copied to a FAT 
diskette the names will be truncated (so 
too when copying to a FAT partition on the 
hard drive). However, the long name and 
other extended attributes will be preserved 
and restored when the file is moved back 
to HPFS, as long as a DOS or Windows 
program has not updated the file and lost 
the extended attributes. 

Bootable DOS diskette 

Regardless of whether or not a major instal¬ 
lation such as a new OS is being consid¬ 
ered, no PC user should be without a 
bootable DOS diskette. To create one, 
place an appropriately-sized floppy in the 
A drive and enter the command FORMAT 
A: /S. The slash-S at the end causes the 
floppy to be formatted as a system disk, 



which means two hidden DOS files are 
copied to the diskette and it is bootable. 
After that it’s recommended that short ver¬ 
sions of the AUTOEXEC.BAT and CON¬ 
FIG.SYS files be created on the floppy 
and several of the more useful DOS files 
should be copied as well (certainly COM¬ 
MAND. COM). Try booting from the diskette 
and running a program or two to be sure 
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If you're building OS/2 (or Windows) 
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the diskette is configured properly. Note 
that this diskette, while handy, is not meant 
to substitute for a complete, official set of 
DOS installation diskettes. 

If all other steps preparatory to installa¬ 
tion have been performed (all files have 
been backed up, network addresses have 
been recorded for the LAN, etc.) then the 
bootable DOS diskette would be a good 
way to experiment with FDISK, assuming 
that the hard drive is about to be reparti¬ 
tioned anyway. FDISK should be one of the 
DOS commands available on the diskette, 
so at this point you could boot the system 
from the A drive and try FDISK from the 
floppy. 

The installation process itself is covered 
quite well by the installation manual that 
comes with OS/2. Read the manual — it’s 
much easier to read than most documenta¬ 
tion from IBM — and it’s so short that it 
barely deserves the title “manual". A couple 
of further points — frequently a few items 
are overlooked, especially if the recom¬ 
mended approach is taken and the soft¬ 
ware is reinstalled from the original disks. 
Record the telephone numbers, as well as 
protocols, passwords and appropriate set¬ 
tings from your communications programs. 


For those who are frequent users of 
Windows, it is recommended you make 
copies of your favorite Windows games 
and applets (particularly if installing OS/2 
without a DOS partition). The version of 
Windows that comes with OS/2, while fully 
functional, can appear a bit spartan due to 
the lack of mini-applications that Windows 
users are accustomed to seeing. In fact ap¬ 
plications written for Windows are some¬ 
times designed to utilize the mini- applica¬ 
tions in the course of their processing. 
Windows games and applets work well un¬ 
der Win-OS/2, provided they are taken 
from version 3 0, not Windows 31. 

Finally, when installation is complete 
and OS/2 is booted up for the first time, be 
patient — it can take as long as 10 minutes 
in some cases. When the Workplace Shell 
is shown, the icons are visible and the disk 
light has at last ceased activity, DO NOT 
USE THE SYSTEM. The very first action to 
perform is a Shutdown and subsequent re¬ 
boot. This does not mean pressing 
Ctrl/Alt/Delete or abruptly turning off the 
power. Avoid those habits with OS/2. To 
Shutdown, click the right mouse button 
once on an empty part of the main screen. 
A pop-up menu will appear and one of the 


options will be Shutdown — click the left 
mouse button to activate it. Proceed with 
Shutdown and reboot the system. There is 
a remote chance of serious file comiption if 
this precaution is not taken. [Some call it a 
bug , others call it a feature , but either way, 
do a Shutdown before using OS/2 for the 
first time.] 

So that’s the first installment of The 
Beginner’s Slope! If it prevents a blunder 
and saves one reader some time, then it’s 
been a success. But never fear; if you’re 
like most users, installation will go smooth¬ 
ly and you’ll enjoy the system more and 
more every day. Soon you’ll cringe if some¬ 
one asks you to use a PC without OS/2! 


Bill Zinsmeyer is a 
programmer with many 
years of experience on 
mainframes who greatly 
enjoys using OS/2 while 
learning more about PCs. He 
can be reached on 
CompuServe at 71031,3436 
and welcomes suggestions 
for future topics. 
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Command Processor for OS/2 
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software 


P.O. Box 1470, East Arlington, MA 02174, USA 


40S2 is a trademark and 4D0S ® is a registered trademark of 
JP Software Inc. OS/2 ® is a registered trademark of IBM 
Corporation. Other company and product names are trademarks 
of their respective owners. Copyright ©1992, JP Software Inc. 
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Gary Murphy 


OS/2 + MIS 


C orporate MIS departments have been enamored with the 
idea of distributed computing for some time. Advances in 
hardware, networks and tools to manage distributed com¬ 
puting are reducing the risk of implementing dient/server solu¬ 
tions in environments that are currently mainframe-centric. Once 
the decision is made to implement a client/server architecture in a 
corporation, data-processing professionals will be asked to help 
their management choose the right platform for their environment. 
Certainly, OS/2 Presentation Manager and DOS plus Windows will 
be two platforms which will be considered as possible can¬ 
didates for deploying the graphical front-end. 

Operational Stability 

In the mid-1980’s, both Microsoft and IBM recognized that the de¬ 
sign of DOS was limited in its ability to support a heavily net¬ 
worked environment. Both companies also recognized the need 
for a better user-interface and the desire by individuals, namely in 
a corporate setting, to be able to have multiple applications avail¬ 
able, perhaps all running at a given time. Applications were also 
growing. What once was seen as acres of memory, the 640K limit 
for DOS has quickly become to be seen as a barrier. OS/2 was 
designed to meet these emerging needs as the ideal multi¬ 
tasking client in a networked environment running large ap¬ 
plications. 

Deploying all or part of mission-critical applications on a desk¬ 
top platform requires that the platform exhibit characteristics that 
are more similar to the mainframe architectures. The operating 
system must protect concurrently running applications from inter¬ 
fering with one another and keep an application from corrupting 
the operating system itself. To assure operational stability, the op¬ 
erating system must also be able to preempt a running application 
to service time-critical components. Finally, an ideal multitasking 
operating system would help ensure that the application with 
which the end-user is interacting provides crisp response, even 
under moderate to heavy load situations. 

The design of OS/2 accommodates all of these needs quite 
w'ell. Microsoft Windows version 3-0 has been a popular and suc¬ 
cessful operating environment for very good reasons. For true 
Windows applications, it has eliminated most of the limits associ¬ 
ated with the 640K barrier of DOS. It provides a good, consistent 
graphical user interface to ease the learning curve when bringing 
in new Windows applications. However, Windows was built on 
the single-tasking DOS operating system and therefore is con¬ 
strained by what it can do. Perhaps its greatest architectural weak¬ 
ness is that all Windows applications share the same address 
space. An errant application can potentially corrupt the data of 
another application, or corrupt the integrity of Windows itself, 
which results in the much-publicized Unrecoverable Application 
Error. Windows, version 31 has code that tries to keep applica¬ 
tions from corrupting the Windows operating environment, but it 


is still expected to offer little assistance in keeping one applica¬ 
tion from interfering with another. 

Operational Synergy 

The bulk of data processing done in most corporations is per¬ 
formed on IBM mainframes operating across SNA networks. When 
choosing the platforms on which to deploy early pilots for 
client/server computing, it is vital to consider the operational and 
support procedures within your organization. Most mainframe sys¬ 
tems programmers have processes in place to collect problem 
source identification and pass it on to the vendor using such tools 
as IBMLink. The support for OS/2 and the Communications 
Manager and Database Manager components are handled much 
the same as their host counterparts in MVS, VTAM, and DB2. 

A result of the design intent of OS/2 to support mission-critical 
applications in a networked environment is the availability of diag¬ 
nostic tools. In the event of a component failure in the operating 
system, OS/2 provides dump and trace facilities that are not avail¬ 
able with older generation desktop operating systems. These diag¬ 
nostic tools contribute to quicker problem resolution time, which 
is essential in supporting a mission-critical application. 

Investment Protection 

If there is an embedded base of applications on the desktop in a 
corporation today, it is likely to be DOS or Windows, not OS/2 
Presentation Manager. OS/2 version 1.3, provides only minimal 
support for DOS and Windows applications and is perhaps the 
greatest barrier to the acceptance of OS/2 by the end-users in 
many corporations. 

The much-discussed OS/2 version 2.0 has the potential to over¬ 
come! that barrier. Support for Windows standard mode applica¬ 
tions and multiple applications is available in the OS/2 v2.0. In 
most environments, the Windows support in OS/2 will match or 
exceed the performance of Windows 3-0. The comparison, howev¬ 
er, needs to be made to Windows 3.1. The performance of 
Windows 3.1 is expected to be better than that of version 3 0 and 
thus should provide a challenge for IBM to come close to its per¬ 
formance characteristics. 

It should be noted that when looking at benchmarks, one 
should not rely on studies that compare a single task on native 
Windows with a single task on OS/2’s Windows emulation. OS/2 
has been shown to be able to better support a moderate to heavy 
workload environment typical of a corporate application engaged 
in client/server computing. If performance issues for Windows ap¬ 
plications are of great concern, it is best for each company to 
benchmark in an environment that better simulates their anticipat¬ 
ed workloads than to depend on published performance reports. 

The other facet of imbedded base is the skill set of the end 
user. Again, if the end-user has experience with a graphical user 
interface, it will be Windows, not the OS/2 Presentation Manager. 
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Migration to the OS/2 Workplace Shell found in OS/2 v2.0 will re¬ 
quire a new learning curve for its user base. The Workplace Shell 
is a next generation graphical user interface. It implements a more 
consistent and flexible way to manipulate the environment, which 
offers considerably more visual clues than in prior-generation user 
interfaces. When assessing the training effort, it is expected that 
the costs would be considerably less than the cost incurred in 
moving from the DOS command line to the Windows or 
Presentation Manager vl.x environments. 

If the training costs become a barrier to implementing OS/2 
v2.0, the Workplace Shell can be implemented to behave in a way 
similar to the Windows 3.0 or the Presentation Manager vl.x inter¬ 
faces. 


testers, it is not possible to know if that projection is a reasonable 
one. For that reason alone, 1 would not recommend that a corpo¬ 
ration make a business decision based on a product as immature 
as NT. 

The recent partnerships formed by IBM with Apple, Motorola 
and others have cast a certain shadow of doubt on IBM’s future in¬ 
tent for OS/2. The ultimate results of these business ventures is not 
known. However, IBM has publicly stated that whatever the result 
of these partnerships may be, there will be an upgrade path for 
OS/2 customers. Based on IBM’s commitment to OS/2 in the past 
and present, it is likely that customers will have an upgrade path - 
at the source code level at the very least — to whatever future pp- 
erating systems are developed in those spin-off companies. 


Native Program Development 

If a company has chosen to develop the application using a third 
generation language and coding to the native API, QS/2 and the 
Presentation Manager offer a great deal more programmer facilities 
than the DOS and Windows APIs. The graphics subsystem in 
Presentation Manager, known as the Gpi, is significantly more so¬ 
phisticated than the corresponding Gdi interface found in 
Windows. Interprocess communications facilities, such as pipes, 
queues and semaphores, are available in OS/2 to facilitate ad¬ 
vanced applications design often found in client/server applica¬ 
tions. There is no counterpart in the Windows environment unless 
the developer is willing to develop a substitute. 

Another key area in the design of a client/server application is 
the support for multiple threads. The simplest client/server design 
would deploy a distinct thread for managing the host connection 
and another thread for supporting the presentation layer of the ap¬ 
plication. Since Windows does not support multiple threads, a de¬ 
veloper implementing a client/server application would have to 
devise a work-around to manage both the presentation services 
and the connection to the remote data. 

Development Tools 

Due to the success of Windows in the marketplace, there are more 
fourth-generation developer’s tools and user interface builders 
available for the Windows environment than the OS/2 Presentation 
Manager environment at present. This does not mean that the 
OS/2 PM environment is without a range of tools to implement 
client/server computing. 

If there is a tool that meets the customers requirements and 
there is no corresponding tool in the Presentation Manager envi¬ 
ronment, then Windows needs to be considered for deployment 
platform for the front-end. Before making this decision, one must 
consider the incremental value of a Windows-based product over 
that which is available in the Presentation Manager environment 
and decide if that value exceeds the value of the increased opera¬ 
tional stability and synergy of OS/2. 

Windows NT and OS/2 Futures 

Microsoft is developing a more robust operating system founda¬ 
tion, known as NT, for the Windows API that overcomes the limi¬ 
tations found in the present DOS environment. While the product 
is not yet available, it is currently being positioned by Microsoft as 
more of a server platform than the ideal client in a networked en¬ 
vironment. Microsoft states that Windows NT will be available by 
early 1993. Until NT is more widely available to alpha and beta 


Conclusion 

The price-performance and the function of desktop computers cre¬ 
ate a compelling reason for companies to look at client/server 
computing. This requires that a decision be made on the desktop 
platform. The role of data processing professionals is to assist their 
managements in making an optimal decision. The needs of every 
corporation vary, but the approach to selecting the right choice is 
the same: Understand the arguments on both sides, weigh their re¬ 
spective importance to the organization and make the decision. In 
most companies with an investment in mainframes, OS/2 is the 
platform of choice. ♦ 


Learn OS/2 
by Simply 
Watching TV! 



As a leader in video training , we are proud to 
announce the addition of IBM OS/2 2.0 to our 
complete line of learner friendly videos. 


Getting Started with OS/2, 2.0.$39.95 

This video tutorial will take the first-time OS/2 user through 
the many setup and installation options. Also learn the 
basics 6f the OS/2 environment. 

Productivity with OS/2, 2.0.$49.95 

This professional training tool will increase \ j 

productivity. Get the most from OS/2 using this 
clear, easy-to-follow video presentation. 

(add $5 for shipping) i 


Sr* if 


Call, send, or fax 
your order to: 

31 S. Adair Street, Pryor, OK 74361 
918/825-6700, 918/825-6744 (tax) 
800/842-4723 (800/VIAGRAF) 


ViaGrafix 

Computer Training Videos 

"The Best in the Business!" 
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World Wide OS/2 Developer Assistance — 

IBM announced thgat it has enhanced the OS/2 Developer 
Assistance program (DAP) to reach software developers around 
the world who are interested in developing OS/2-based products. 
Developers can apply for DAP membership by calling 407-982- 
6408 to receive a sign-up form via fax, or by typing “GO OS2DAP’ 
on CompuServe and completing the electronic sign-up form. In ad¬ 
dition to current CompuServe support and country-specific 
electronic services — such as IBMLink in the U.S. — IBM int 
ends to use CompuServe as one of the primary worldwide distrib¬ 
ution sources for OS/2 product technical and marketing informa¬ 
tion. 

IBM also announced that it will offer a beta version of OS/2 2.x 
code, beta version of varous IBM OS/2 development tools and 
programming technical information on a CD-ROM that is being dis¬ 
tributed in a pilot program. There will be a shipping and handling 
fee for the CD-ROM. Installation support will be provided to pro¬ 
grammers via the CompuServe “OS2DEV’ forum, section 16 “DE¬ 
VELOPERS CD ROM.’ License for the code contained on the CD- 
ROM expires December 15, 1992. 

The CD-ROM contains: OS/2 2.x 32-bit graphics engine beta; 
Windows 3.1 API support for win-OS/2; IBM developers toolkit for 
OS/2 2.0; Beta version of an enhanced IBM WorkFrame/2; IBM C 
Set/2 (latest Beta with VDD and new linker); profiler for C Set/2; 
MMPM/2 plus toolkit; NTS/2 beta code; Netware Workstation kit 
for OS/2 2.0; TCP/IP Ver 1.2.1 for OS/2; IBM OS/2 2.0 “Red 
Books”; IBM OS/2 2.0 Technical Library; 26 productivity tools (IBM 
employee-written software) 

IBM, 1133 Westchester Ave., White Plains, NY 10604. Contact 
Rob Crawley, 914-642-5364. 

Automated Test Facility (ATF 2.0) 

Softbridge announces automated test facility (ATF 2.0). ATF is a 
software system designed for unattended testing of applications 
written under Windows, OS/2, and Dos, either standalone or in 
networked environments. ATF 2.0 provides powerful new features 
that increase the product’s breadth while dramatically improving 
ease of use. 

Softbridge, Inc., 125 Cambridge Pd Dr., Cambridge, MA 02140, 
617-576-2257. 

BenchTech for OS/2 

BenchTech for OS/2 is a powerful performance measurement tool, 
containing a suite of 32-bit benchmarks designed specifically for 
OS/2 version 2.0 and beyond. OS/2 2.0 performance can vary 
greatly between one computer and another. Even though all 
systems that run OS/2 2.0 are based on INTEL 386 architecture, 
the observed performance is also dependent on the chase design 


(if the system uses a cache), the number of wait states required, 
the video system, the disk drive and many other factors. 

BenchTech for OS/2 allows you to measure integer and floating 
math performance, data movement and memory access. There are 
three separate disk tests, and you control whether the program 
uses the OS/2 system disk cache. The program allows you to de¬ 
termine relative video performance using any of eight video tests. 
Three application oriented tests are included or you can specify 
your own OS/2, DOS, or Windows test. Two higher level bench 
mark tests are included for comparing systems. Twenty-five bench¬ 
mark tests are included in all. 

Synetic Systems, 2210 Highway 6 & 50, Suite 204, Grand 
Junction, CO 81505-9406, 303-241-1717. 

FactslinkPRO 

FactslinkPRO development system is a comprehensive interactive 
voice/fax software package. It includes complete voice mail, fax 
mail, auto attendant, fax retrieval, database interaction and order 
entry capabilities in a single package. It runs with popular third- 
party computer fax board and voice board hardware. Applications 
can have up to 60 voice lines, and up to 30 fax lines per computer. 

Voice Link, Inc., 1840 Oak Ave., Evanston, IL 60201, 708-866- 
0404. 

CCC/Manager for OS/2 2.0 

CCC/Manager for OS/2 2.0 is part of Softools’ CCC (Change and 
Configuration Control) product family, which provides extensive 
life cycle management functionality across all major platforms, in¬ 
cluding IBM, Digital, Unix and the PC. The product allows change 
and version control for all software components, support for all 
phases of life cycle, turnover and migration management, impact 
management, and cooperate across platforms through CCC/Bridge 
products. 

Softool Corp., 340 S. Kellogg Ave., Goleta, CA 93117, 805-683- 
5777. 

Sizelt 

Sizelt, a new MS-DOS software utility that enables users to quickly 
and easily print ascii text files, using their printers built-in scalable 
fonts. Through Sizelt’s menu driven interface, users select typeface, 
pointsize, page orientation, margins, headersize and other page 
layout and formatting options. This should be particularly interest¬ 
ing to Canon LPB-4 and LPB-8 printer users. However, many 
spreadsheet database, and other more specialized software appli¬ 
cations still lack Canon support. Canon still has not yet delivered 
an OS/2 printer driver. This utility supports drag and drop printing 
now for plain text objects, allowing users to print ascii text any 
way they like, under OS/2. Succinct is now beta testing support for 
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the HP III series. 

Succinct Systems, Inc., PO Box 281, Norwich, VT 05055, 802- 
649-5144. 

OS/2 Compatible Tape Drives 

Cristie, the data security company is launching two ranges of OS/2 
compatible tape drives that can be connected by way of PC’s 
Parallel printer port. This makes them easy to install and low cost 
to share. The TS4000 OS/2 and TS5000 OS/2 ranges include units 
with capacities from 60 M-bytes to 4.5 GBytes. It includes AT and 
MCA adaptor cards as well as the parallel printer port option. Each 
unit is provided with software to back up, restore and catalogue 
individual or groups of files. This can be operated via icons under 
Presentation Manager and is HPFS compatible. 

Cristie Electronics Limited, Bonds Mill, Stonehouse, Glos. 
GL103RG, United Kingdom (045 382) 3611. 

PM/Focus 

PM/Focus offers OS/2 application developers a rich graphical 
toolset complete with file painter, forms painter, and Query Painter 
to build even the most complex applications without writing code. 
Application components such as databases, forms and procedures 
are transformed into simple graphic objects that can be moved, 
manipulated and activated with a point, click and drag of your 


mouse. PM/Focus can take advantage of Information Builders’ new 
Enterprise Data Access “EDA/SQL” technology. This means you 
can have access to more than 50 relational and non-relational file 
types on over 35 operating platforms. 

A comprehensive set of list boxes, checkboxes, radio buttons, 
type fonts and other graphical images allows you to create attrac¬ 
tive, intuitive applications user interfaces. PM/FOCUS OS/2 
LANpak is available in 4, 16, 32 and larger user configurations. 

Information Builders, Inc., 1250 Broadway, New York, NY 
10001-3782, 212-736-4433. 

SQA:Replay 

SQA:Replay is a new utility that allows users to record every key¬ 
stroke, mouse movement and mouse click for playback at a later 
time. It is able to work in either full-screen character mode or with 
PM window, and no interference with user applications. Major re¬ 
play features include the automatic restoration of the desktop or¬ 
der before replay begins, variable speed playback, the ability to se¬ 
lectively pause during playback, and unattended playback. It is 
upgradable to SQA:Robot, a full-featured test regression tool. 
SQA:Replay scripts can be used by SQA:Robot. SQArReplay works 
under version 1.3 and 2.0 of OS/2. 

Software Quality Qutomation, 1 Parker St., Lawrence, MA 
01843. ♦ 


= PERFORMANCE 2.0 

"Go as fast as 32 bits will take you” 

A Tuning Kit for OS/2 2.0 



PERFORMANCE 2.0 is both an instructional booklet and 
a diskette with a collection of program objects to help you tune your system. 

THE BOOKLET - 60 pages - the best source for OS/2 Tuning Information. 


BASIC section clearly describes a 32 bit, preemptive multitasking, multi-threading, 
demand paging virtual memory system , written for the novice! 

DETAIL section focuses on those tip, techniques, and parameters that explain 
HPPs, EAT, Caching, Buffering, Swapping, Fragmentation, Multithreading, 
Timeslicing, and more - written for the advanced user ! 


THE DISKETTE - 25+ software OBJECTS - REXX source code included 
These objects are designed to help you tune your system with SIMPLICITY. 

OPTIMIZERS are the easiest objects to use. They assess your system, make 
recommendations and will perform a tune-up for you. 

TOOLS are objects that tune individual parts of your system, such as Swap size, 
Buffers, Cache parameters, etc. Tools require some skills to operate. 

ELIMINATORS are a reverse engineering of 0S/2's selective install allowing 
you to selectively delete the files associated with a selective install. 


All for $19.95 + 2.50 S&H 

send Check or M.O. $22.45 to: CLEAR & SIMPLE, INC 

or call (203) 658-1204 P.O. Box 130 

VISA & MC Accepted W Simsbury, CT 06092 

Ask about our new File Distribution System for Local Area Networks 

OS/2 is a registered trademark of International Business Machines, Corporation 


Peter D. Norberg 


Professional Solutions 
to 

Professional Problems 


• Convert DOS/Windows to OS/2 

• DLL Design 

• Devise Driver Implementation 

• Expert C and Assembly Language Work 

PDNVDISK - 

The HUGE Ram Disk for OS/2 


Call: (314) 647-8487 

P.O. Box 9330 Richmond Hts, MO 63117 
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ADVANCED PM PROGRAMMING 
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GUY SCHARF is president of 
Software Architects, Inc., 
2163 Jardin Drive, Mountain 
View, CA 94040. Software 
Architects, Inc. specializes 
in OS/2 Presentation 
Manager software develop¬ 
ment and consulting. Guy 
can be reached on the 
CompuServe 0S2DEV forum 
or on CompuServe Mail at 
76702,557 or through 
Internet at 76702.557@com- 
puserve.com. 


Introducing Containers 

OS/2 2.0 introduces four new controls: slider, 
value set, notebook, and containers. This month 
we will take a first look at containers. 

First, what is a container? You have seen con¬ 
tainers lots of them. The container control is one 
of the key components of the Workplace Shell. A 
container displays to the user the items, or ob¬ 
jects, in contains in a visual way. Virtually every¬ 
thing you see on the OS/2 desktop before start¬ 
ing a program or opening a settings view is a 
container. 

If you open the drives folder, select a drive, 
and open it, you will see a container showing 
directories on the drive, arranged hierarchially. 
This representation is called a tree view. Select 
Open from the system menu again, press the 
right arrow button, and you can open Settings, 
Icon view, Tree view, and Details view. These 
three views are all different ways a contain¬ 
er can display the directories and files on a 
drive. 

The container control supports five views of 
its contents: 


State Information 


State Information Table 
(1987 Almanac) 



Population 


State 

Capitol 

(1980 Census) 






Alaska 

Juneau 

401,851 


Arizona 

Phoenix 

2,718,425 


Arkansas 

Little Rock 

2,286,-135 


California 

Sacramento 

23,667,565 


Colorado 

Denver 

2,889,735 


Connecticut 

Hartford 

3,107,576 


Delaware 

Dover 

594,317 


Florida 

Tallahassee 

9,746,342 

v 

V 



... .. c >1 CO i nr 



i 

> 



OK 


Cancel 


Figure 1 


Icon View Icons or bitmaps with strings be¬ 
neath. The Workplace Shell desktop normal¬ 
ly displays objects this way. 

Name View Icons or bitmaps with text to the 
right. 

Text View Text strings without any pictorial 
representation. 

Tree View Icons or bitmaps with text to the 
right and with a way to display a hierarchy 
(often indicated by + and - signs). 

Details View Icons or bitmaps, text strings, 
numbers, times, and/or dates. 

Container windows support direct manipula¬ 
tion the user can select items with the mouse 
and drag them around. The user can drag items 
and drop them onto other containers, applica¬ 
tions, or windows. 

It is the container control that gives OS/2 2.0 
and the Workplace Shell much of its flavor. 

A container may change the way in which its 
contents are displayed by changing the view. In 
the Workplace Shell, different views are typically 
seen by opening windows with that alternate 
view. It is possible to change the view within a 
single window. Only one view can be displayed 
in one container window' at a time. 

A Step at a Time 

As you might imagine, a control that performs all 
of these functions and many more and shows 
data in all of these views is complex. The docu¬ 
mentation is daunting. The CUA Library/2 manu¬ 
al has 34 pages describing the container control 
and how it works and 74 pages of programming 
reference material. The documentation for the 
container control is larger than that for any of the 
other new controls. 

Here, we will cut the problem dowm to a sim¬ 
pler case we will use the details view of a con¬ 
tainer to build a multi column listbox with 
scrolling, container and column titles, and other 
bells and whistles. Programmers frequently need 
multi-column listboxes for applications. While 
you can use the owner-draw feature of the list- 
box control to do that, the container with its de¬ 
tails view is easier and more powerful. 

Figure 1 shows a dialog with a container de- 
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tails view that is displayed by the sample 
program. Look at some of its features that 
you could not easily achieve in a list box: 

• The container has a two-line, centered 
heading that does not scroll. This head¬ 
ing is part of the container itself; it is not 
static text outside of the container. A hor¬ 
izontal line is placed beneath the head¬ 
ing. 

• The columns have headings too. Some of 
the headings are left justified, some are 
right justified. These headings also have a 
horizontal separator line beneath them. 

• The container has a vertical scroll bar. 
The scroll bar does not extend to the 
headings, indicating that the headings 
stay fixed as you scroll the container ver¬ 
tically. 

• The container has a vertical double line 
between the first and second columns. 
Grab the line with the mouse and you 
can drag it left and right. This is called a 
split bar. The split bar separates the con¬ 
tainer into two pieces, each of which is 
individually scrolled horizontally. You 
can adjust the split of the window into 
two pieces by dragging the split bar. 

If you scroll the container horizontally, 
the column headings scroll too. 

• The data in the columns is formatted. 
Text strings are left-justified; numeric val¬ 
ues and dates have correct punctuation 
as specified by the system settings and 
are right-justified. 

This looks complex, but is all pretty easy 
to do. Let’s first look at the basics of pro¬ 
gramming a container. 

Container Basics 

The basic steps for programming a contain¬ 
er are the same as for other controls you are 
familiar with. You must create the contain¬ 
er, load it with data, possibly monitor or 
modify its operation, possibly retrieve data 
from the container, and shut the container 
down when you are done with it. However, 
the container control requires more com¬ 
plex setup than older controls. 


Creating a Container 

As with other control, you create a contain¬ 
er by placing a CONTROL statement in a re¬ 
source script. WC_CONTAINER is the win¬ 
dow class name (CCL_CONTAINER if you 
are using CUA Library/2). You can also cre¬ 
ate a container programmatically using Win- 
Create Window. 

In the sample program, the container is 
in a dialog box. In the Workplace Shell dri¬ 
ve folders, the containers occupy the entire 
window. That difference is a design choice. 
For the sample program, I wanted the ap¬ 
pearance of a list box in a dialog. 

The container control supports a small 
set of style flags. We look here only at those 
that apply to the details view. 

CCS_READONLY makes the entire con¬ 
tainer read-only. If you don’t make the con¬ 
tainer read-only, the user can modify the 
container title and container records. If you 
want to modify some data, but not all, you 
would omit this style and later mark con¬ 
tainer titles, records, column titles, or col¬ 
umn contents that are not to be changed as 
read-only. 

CCS_SINGLESEL specifies that only one 
container item can be selected at a time. 
CCS_MULTIPLESEL allows the user to select 
zero or more items. Both of these are simi¬ 
lar to listbox styles. The container control 
also has the CCS_EXTENDSEL style, which 
allows the user to select one or more con¬ 
tainer items. 

CCS_MINIRECORDCORE specifies that a 
smaller record structure is to be used for 
this container. Records are a*key concept of 
containers. We examine them in the next 
section. 

Notice that the type of view was not 
specified as a style, and other information is 
not yet known either. You must initialize 
the container programmatically using the 
CM_SETCNRINFO message. We’ll look at 
that later. 

Understanding Container Items & Records 

A container item is anything the user or 
programmer might store in a container. The 
container is really a very general purpose 
object, and can hold many different types of 
items. Car, truck, bicycle, and unicycle ob¬ 
jects could all be stored in the same con¬ 
tainer. 

Programmatically, the data for each item 
in the container is stored in a record. The 


container control manages the records. The 
programmer asks the control to allocate 
memory for the records, fills in the fields of 
the record, and tells the container to insert 
the records in the container. When the con¬ 
tainer window is closed, the container frees 
the memory for the records. 

All records of a container must have the 
same structure. There are two issues in de¬ 
termining the record format: 

• Whether the full-sized record format 
(RECORDCORE) or a small record format 
(MINIRECORDCORE) should be used. 

• How much additional space should be 
included in each record for programmer- 
maintained data. 

The basic record structure (RECORD- 
CORE or MINIRECORDCORE) has control 
information used by the container to main¬ 
tain the records. 

The MINIRECORDCORE structure con¬ 
tains only the minimum information neces¬ 
sary for a container item: a pointer to a 
text string, a handle to an icon, a chain 
pointer to the next record, the position of 
the icon in an icon view, and some attribute 
flags. 

The larger RECORDCORE structure con¬ 
tains the above information plus more. 
RECORDCORE supports different text 
strings for text, name, and tree views. 
RECORDCORE is the default data structure. 
If you wish to use MINIRECORDCORE, you 
must specify the CCS.MINIRECORDCORE 
style when creating the container. 

The information in these data structures 
is sufficient to control the basic operation of 
a container, but is usually not sufficient for 
an application. Also, many of the items in 
the structure are pointers to strings. Where 
are the strings stored? If the strings are in 
memory the programmer has allocated, 
then that memory must remain allocated for 
the life of the record. That may not be con¬ 
venient. 

The container control allows you to ap¬ 
pend any information to the basic record 
structure. When you ask the container to 
allocate memory, you tell it how many 
extra bytes you want allocated in each 
record. The usual way to program this is to 
declare a C struct. The first element of the 
struct will be RECORDCORE or MINI- 
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RECORDCORE. The following elements are 
your data fields. For example: 

typedef struct 

I 

MINIRECORDCORE RecordCore; 

ULONG ulMyNumber; 

CHAR szMyString[10l; 

CD ATE cdate; 

) USERRECORD, *PUSERRECORD; 

You ask the container to allocate memo¬ 
ry for one or more records by sending a 
CM_ALLOCRECORD message. To be more 
efficient, allocate many records at the same 
time. 

Now, complete the record contents. 
Assign values to elements in both the base 
record structure and the extra bytes that fol¬ 
low the base structure. 

After completing the records, you insert 
them into the container by completing a 
RECORD1NSERT structure and sending the 
address of it and the first record allocated to 
the container with a CM_INSERTRECORD 
message. 

When the container terminates, it will 
free the memory it allocated for you. 
However, if you used mallocO to obtain 
any additional space while filling in the 
records, the container cannot release that 
space, since it does not know about it. 
Instead, you will need to examine the 
records, perhaps while processing the 
WM_DESTROY message to the dialog, and 
free any additional space you allocated. 

You may remove or insert additional 
records in the container at any time. 

Container Columns 

The details view shows several columns of 
information. As you might expect, these 
columns require additional control informa¬ 
tion so that the container can manage the 
columns. 

In a way similar to managing records, 
you ask the container to allocate column 
control structures with the CM_ALLOCDE- 
TAILFIELDINFO message. You then com¬ 
plete the FIELDINFO data structures with 
information about each column. Finally, 
you construct a FIELDINFOINSERT structure 
and insert the column information with a 
CMJNSERTDETAILFIELDINFO message. 

As with records, you can remove or in¬ 
sert additional columns at will. 


Unlike container records, the container 
does not allow you to add extra bytes to the 
column control data. Instead, the FIELDIN¬ 
FO structure contains a pUserData field that 
you can use to hold a pointer to your infor¬ 
mation. 

Example Program 

The example program constructs a details 
view container that lists the states of the 
Union, their capital cities, their population 
according to the 1980 census, and the dates 
they were admitted. The container can be 
scrolled vertically and horizontally. A split 
bar allows the user to adjust the amount of 
space in which the state name is displayed. 

The Resource Script 

Let’s look first at the CNRDTL.RC file. As 
usual, all strings that the user might see are 
placed in a STRINGTABLE. No user-visible 
text is allowed in the program code. All of 
the strings are container or column head¬ 
ings. The \012 in the strings is a new-line 
character, forcing that heading to be dis¬ 
played in two lines. 

The dialog template contains a CON¬ 
TROL statement for a window of WC_CON- 
TAINER class. The user may select only one 
item at a time (CCS_SINGLESEL) and cannot 
modify any data (CCS_READONLY). The 
program uses the minimal record structure 
(CCS_MINIRECORDCORE). 

A PRESPARAMS statement follows to set 
the font within the container to 8 point 
Helvetica. A \0 is included at the end of the 
font name string. This is required to make 
PRESPARAMS work with OS/2.0. This extra 
null is not required with OS/2 1.3. 

The container control itself has no mar¬ 
gin surrounding it. This makes it especially 
easy to use when the entire client area of a 
window is occupied by a container. We 
used the GROUPBOX statement to place a 
margin around the container for appear¬ 
ance’s sake. This GROUPBOX statement 
should follow the CONTROL statement for 
the container itself. 

Main Program 

First, we define sample state data. Each 
record has the state and capital names, pop¬ 
ulation, and date admitted. 

Next we define the container record 
structure, RECORD. The first element of this 
structure must be MINIRECORDCORE (or 


RECORDCORE if desired). We then add 
three fields that represent the columns to be 
displayed: a pointer to the capital name, 
population of the state, and the date ad¬ 
mitted. We’ll examine the data types and 
the following COLDESC data in the next 
module. 

The main program simply runs the ex¬ 
ample dialog and terminates; it is of little in¬ 
terest itself. 

Finally, we come to the dialog proce¬ 
dure, ExampleDlgProcC). The dialog proce¬ 
dure for this program is extremely simple. 
In WM_INITDLG, CnCreateDetailsViewQ 
defines the columns of the details view and 
InitContainer() loads the state data into the 
container. In WM_COMMAND, we dismiss 
the dialog when a button is pushed. In 
WM_DESTROY,CnDestroyDetailsView() 
frees memory allocated for the container. 

Creating the Details View 

CnCreateDetailsViewC) is a utility function 
in CNFUNC.C to initialize the details view of 
a container, based on control structures 
passed to it. This function requires the num¬ 
ber of columns, a pointer to the column 
control structure, the column the split bar is 
to follow, the position of the split bar as a 
percentage of the container width, the 
STRINGTABLE id of the container heading, 
and a handle to the resource module con¬ 
taining the STRINGTABLE. 

The column information is the COLDESC 
data in CNRDTL.C. The COLDESC data con¬ 
tains an offset to the data within the record, 
column attribute flags, a STRINGTABLE id 
for the column heading, an optional width 
for the column, and an NULL pointer used 
within CnCreateDetailsViewC). 

The first thing CnCreateDetailsView does 
is go through the table of column descrip¬ 
tions, load the column titles from the re¬ 
source file, and place pointers to the tide 
text in the pszTitle field of the structure. 

Next we initialize the container itself. We 
clear the CNRINFO structure on the stack 
and set the structure size in cb. We set the 
container attributes field in 
cnrinfo.flWindowAttr to CV_DETAIL (details 
view), CA_DETAILSVIEWTITLES (we want 
column titles), CA_CONTAINERTITLE (we 
want a title area for the container itself), 
and CA_TITLESEPARATOR (we want a hori¬ 
zontal line under the container title). 

Then we load the container title from the 
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resource file and place a pointer to it in cn- 
rinfo.pszCnrTitle. The title contains a new- 
line character (\012), which causes the title 
to appear as two lines. 

The CNRINFO structure contains a great 
many fields. When we send the CM_SETCN- 
RINFO structure to the container, we must 
tell it what parts of the CNRINFO structure 
should be examined. We tell it this with 
CMA_* flags OR’ed together in mp2. In this 
case, we say CMA_FLWINDOWATTR (set 
window attributes) and CMA_CNRTITLE 
(set the title text). Those are the only two 
fields in CNRINFO that we filled in. If we 
had completed other Fields, we would have 
needed to specify other CMA_* values to 
ask the container to pay attention to those 
fields. 

Now that we have established the con¬ 
tainer, we can define the columns. First, we 
use the CM_ALLOCDETAILFIELDINFO mes¬ 
sage to ask the container to allocate the col¬ 
umn control structures for the number of 
columns we need. The container returns to 
us a pointer to the first FIELDINFO struc¬ 


ture. The other structures have been allocat¬ 
ed and chained to this structure. The struc¬ 
tures have been initialized as zero except 
for the structure length and chain fields. 

We now loop through the COLDESC ar¬ 
ray, filling in one FIELDINFO structure for 
each COLDESC entry. 

We copy the field offset and the attri¬ 
butes from COLDESC. These attributes are 
key to the operation of the column. You 
must specify the type of field this is. Details 
view supports CFA_ULONG (offset is to a 
ULONG), CFA_DATE (offset is to a CDATE 
structure), CFA_TIME (offset is to a CTIME 
structure), CFA.BITMAPORICON (offset is 
to an HPOINTER), or CFA_STRING (offset is 
to a PSZ, not to a CHAR array as the name 
might suggest). We can specify the justifica¬ 
tion of the data (CFA_LEFT, CFA.RIGHT, 
CFA_CENTER), vertical positioning of data 
in the row (DT_VCENTER, DT_TOP, 
DT_BOTTOM), and visual attributes 
(CFA_HORZSEPARATOR for a separator be¬ 
low column headings, CFA_SEPARATOR for 
a vertical separator to right of column, 


CFAJNVISIBLE, CFA_FIREADONLY for a 
read-only field, CFA_OWNERDRAW). 

We don’t use any bitmaps or time values 
in this sample. The CDATE and CTIME 
structures are sets of three ULONG values. 
The container will format them according to 
the current system preference settings. 

We copy the title attribute and mark the 
title read-only. We use CFA_LEFT and 
CFA_RIGHT on columns to left or right jus¬ 
tify the column headings. Since the contain¬ 
er has the CCS.READONLY style, CFA_FITI- 
TLEREADONLY does not add anything. We 
have no user data and set the column width 
to 0. With a 0 width, the container will de¬ 
termine the width of the columns based on 
the data to be displayed. We could have set 
a width of our own choice if we wished to. 

Setting the split bar requires modifying 
the container setup information. It is not 
part of the FIELDINFO information as such. 
We need to set a pointer to the last FIELD¬ 
INFO that is left of the splitbar, and specify 
the position of thesplitbar. To determine the 
position, we get the dimensions of the con- 
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tainer window and calculate the percent of 
that width that was passed as a parameter. 
We set the calculated x position and the 
pointer to the last FIELDINFO in the CN- 
RINFO structure. Finally, we send a 
CM_SETCNRINFO message to the container, 
specifying which fields we have set 
(CMA.XVERTSPLITBAR for the location, 
and CMA_PFIELDINFOLAST for the last col¬ 
umn to the left of the split bar). 

Having completed all FIELDINFO struc¬ 
tures, we construct a FIELDINFOINSERT 
structure, tell it how many structures we 
want to insert, and insert the fields by send¬ 
ing CMJNSERTDETAILFIELDINFO. 

Loading the Container 

Now we are ready to load the container us¬ 
ing InitContainerO in CNRDTL.C. First, we 
ask the container to create the records. The 
number of extra bytes is the difference be¬ 
tween our RECORD size and the system’s 
MINIRECORDCORESIZE. The container al¬ 
locates the requested records, initializing 


them to zero except for the size and chain 
fields. 

All we need to do is to run the chain 
and our array of state data, copying infor¬ 
mation into the RECORD structure. We 
used the pszlcon field, which is the name 
of the item, as a pointer to the state name. 
We used the pszCapital name we created 
for the capital city. We could have used our 
own pointers for both. We could also have 
added CHAR fields for these names in the 
RECORD structure and copied the actual 
strings in. However, if we had done that, 
we would still have had to have PSZ val¬ 
ues, as the CFA_STRING must specify the 
offset of a PSZ, not the beginning of a 
string. 

Next we create a RECORDINSERT struc¬ 
ture, give it the number of records, tell it 
where to insert these records, and insert the 
records with a CM_INSERTRECORD mes¬ 
sage. 

We’re done. The container is now up 
and running. Since this is a read-only dis¬ 


play container, we don’t have to do any¬ 
thing until the user terminates the dialog. 

Shutting Down 

While initializing the container and details 
view, we allocated memory with malloc. 
When the container closes, we need to free 
that memory to prevent a memory leak. 
Upon receipt of WM_DESTROY, the dialog 
calls CnDestroyDetailsViewO. Here we free 
the strings loaded from the resource file. 
We read the CNRINFO data and free the 
container title text that we allocated. Next 
we free the column data and all records. 

In this example, freeing the column data 
and records is not required, as the container 
will free that memory. However, if we had 
been doing something else, such as switch¬ 
ing from a details view to a tree view, we 
might have wanted to free the column data 
before the container terminated. 

Summary 

There you have it a multi-column listbox 
with titles, column headings, vertical splits, 
and nice formatting. Later, we can add 
many more features direct manipulation 
(drag/drop), direct editing of column data, 
and more. 

The programs in this article are available 
on the OS2DEV forum on CompuServe. GO 
OS2DEV and download file CNRDTL.ZIP 
from library 4, Ver 2.0. 
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LISTING 1. CNRDTL.C 


// cnrdtl.c — Sample program to demonstrate container detail 


MINIRECORDCORE RecordCore; 
PSZ pszCapital; 

ULQNG ulPopulation; 

CDATE cdateAdmitted; 

) RECORD, *PRECORD; 


// MINIRECORDCORE structure 
// Capital city 
// Population 
// Date admitted 


//- 

// cnrdtl.c 

// 

// Sample program to demonstrate container detail view 

// 

// By; Guy Scharf (415) 940-9186 

// Software Architects, Inc. FAX: (415> 948-1620 

// 2163 Jardin Drive 

// Mountain View, CA 94040 

// CompuServe; 76702,557 

// Internet: 76702.557@compuserve.com 

// (c) Copyright 1992 Software Architects, Inc. 

// 

(1 All Rights Reserved. 

// 

// Software Architects, Inc. develops software products for 
// independent software vendors using OS/2 and Presentation 
// Manager. 

//- 


COLDESC cdState[] - 

( 

{Of fsetof(RECORD, RecordCore.pszlcon), CFA_STRING I CFA_FIREADONLY 

I 

CFA_HORZSEPARATOR | CFA_LEFT, IDS_HEAD_STATE, 

CFA_LEFT, 0, NULL}, 

{offsetof(RECORD, pszCapital), CFA_STRING | CFA_fIREADONLY | 
CFA_HORZSEPARATOR | CFA_LEFT, IDS_HEAD_CAP, 

CFA_LEFT, 0, NULL}, 

{offsetof(RECORD, ulPopulation), CFA_ULONG | CFA_FIREADONLY | 
CFA_HORZSEPARAfOR | CFA_RIGHT, IDS_HEAD_POP, 

CFA_RIGHT, 0, NULL}, 

{offsetof(RECORD, cdateAdmitted), CFA_DATE | CFA_FIREADONLY | 
CFA_HORZSEPARATOR | CFA_RIGHT, IDS_HEAD_ADM, 

CFA_RIGHT, 0, NULL} 

}; 

// Prototypes of procedures 


#define INCL_PM 
#define INCL_BASE 
♦include <OS2.H> 

♦include <stdlib.h> 
♦include <stddef.h> 
♦include <string.h> 

♦include "cnrdtl.h" 
♦include "cnfunc.h" 


// Sample data 


// Basic OS/2 PM 
// components 


Static MRESULT EXPENTRY ExampleDlgProc (HWND, MSGID, MPARAM, 

MPARAM) ,* 


// C runtime library 


// Container demo defs 
// Container utilities 


static MRESULT InitContainer 
HWND hwndDlg, 

USHORT idContainer, 

USHORT estates, 

PSTATEREC pastate); 


// Initialize slider 
//I - Dialog window 
//I - Container id 
//I - Number of states 
//I - State data array 


//- 

// 

// Main program to drive container example 

// 

//- 


typedef struct 

{ 

SHORT mm, dd, yy; // General date storage 

} OURDATE, *POLJRDATE; 

typedef struct 
{ 


PSZ 

pszState; 

// 

Name 

of state 

PSZ 

pszCapital; 

// 

Name 

of city 

ULONG 

ulPopulation; 

// 

'80 i 

census population 

OURDATE 

ourdateAdm; 

// 

Date 

admitted 

STATEREC, 

, *PSTATEREC; 





int main (void) 
{ 


HAB 

hab; 

// 

Handle to anchor blk 

HMQ 

hmqMsgQueue; 

// 

Handle to msg queue 

♦ifndef 

OS220 



HMODULE hmodContainer; 

// 

Handle to entr module 

♦endif 




hab 

= Winlnitialize (0); 

// 

Initialize PM 


hmqMsgQueue = WinCreateMsgQueue (hab, 0);// Create msg queue 


STATEREC statedata[) 






♦ifndef OS220 


{ 






if (DosLoadModule (NULL, 0, CCL_CONTAINER_DLL, 

{"Alabama", 

"Montgomery", 

3893888, 

(12, 

14, 

, 1819}}, 

ShmodContainer)) 


{"Alaska", 

"Juneau", 

401851, 

{ 1, 

3, 

1959}), 

return FALSE; 


{"Arizona", 

"Phoenix", 

2718425, 

{ 2, 

4, 

1912}}, 

♦endif 


{"Arkansas", 

"Little Rock", 

2286435, 

{ 6, 

15, 

, 1836)}, 



{"California", 

"Sacramento", 

23667565, 

{ 9 , 

9, 

, 1850}}, 

WinDlgBox (HWND_DESKTOP, HWND_DESKTOP, 

ExampleDlgProc, 

{"Colorado", 

"Denver", 

2889735, 

{ 8, 

1, 

. 1876}}, 

IDLG_EXAMPLE, NULL); 


{"Connecticut", 

"Hartford", 

3107576, 

{ 1, 

• 9, 

, 1788)), 



{"Delaware", 

"Dover", 

594317, 

(12, 

7, 

■ 1787}), 

♦ifndef OS220 


("Florida", 

"Tallahassee", 

9746342, 

{ 3, 

3, 

, 1845}}, 

DosFreeModule (hmodContainer); 


{"Georgia", 

"Atlanta", 

5463105, 

{ 1, 

2, 

. 1788)}, 

♦endif 


{"Hawaii", 

); 

"Honolulu", 

964691, 

{ 8, 

21, 

, 1959)} 

WinDestroyMsgQueue (hmqMsgQueue); // 

WinTerminate (hab); 

Shutdown 

typedef struct 

{ 


// Container 

data record 

return 0; 

I 
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// - 

// 

// ExampleDlgProc() - Show state info 

// 

// - 

static MRESULT EXPENTRY ExampleDlgProc ( 

HWND hwndDlg, 

MSGID msg, 

MPARAM mpl, 

MPARAM mp2) 

{ 

switch(msg) 

{ 

// - 

// Initialize dialog by defining the details view 
// in the container, loading records, etc. 

//- 

case WM_INITDLG: 

CnCreateDetailsView (WinWindowFromlD (hwndDlg, 

IDCN_STATEINFO), 
sizeof cdState / sizeof (COLDESC), 
cdState, 

0 , 

33, 

IDS_TITLE, 

0 ) ; 


//- 

// Load the container 

//--- 

InitContainer (hwndDlg, IDCN_STATEINFO, 

sizeof statedata / sizeof (STATEREC), 
statedata); 

return 0; 


//- 

// Process pushbuttons. They both just quit dialog. 
//- 

case WM_COMMAND: 

switch (SHORT1FROMMP(mpl)) 
i 

// Cancel pressed 
// Dismiss dialog 

case DID_CANCEL: 

WinDismissDlg (hwndDlg, FALSE); 
return 0; 

//OK button pressed 
case DID_OK: // We're done 

WinDismissDlg (hwndDlg, TRUE); 
return 0; 

) 

return 0; 


//- 

// Recover memory allocated for the container 
//- 

case WM_DESTROY: 

CnDestroyDetailsView (WinWindowFromlD (hwndDlg, 

IDCN_STATEINFO), 
sizeof cdState / sizeof (COLDESC), 
cdState); 

return 0; 


//- 

// All other messages go to default window procedure 


// - 

default: 

return (WinDefDlgProc (hwndDlg, msg, mpl, mp2>); 

1 

return FALSE; 


//- 

// Function: InitContainer 
// Outputs: none 

// 

// This function loads the container with all of the state data. 
// See the article for a complete discussion of this function. 

//- 


static MRESULT InitContainer ( 
HWND hwndDlg, 

USHORT idContainer, 

USHORT estates, 

PSTATEREC pastate) 

( 

USHORT i; 

ULONG cbExtraBytes; 

structure */ 


// Initialize slider 
//I - Dialog window 
//I - Container id 
//I - Number of states 
//I - State data array 

// Loop counter 
// Extra bytes in record 


PRECORD precord; 

PRECORD precordFirst; 


// -> container records 
// -> first container record 


RECORDINSERT recordlnsert ; 


// Record insertion control 


//- 

// Allocate memory for all user records 

//- 

cbExtraBytes = (ULONG)(sizeof(RECORD) - 

sizeof(MINIRECORDCORE)); 

precord = (PRECORD) WinSendDlgltemMsg (hwndDlg, idContainer, 
CM_ALLOCRECORD, 

MPFROMLONG (cbExtraBytes), 
MPFROMSHORT (estates)); 

precordFirst = precord; 

//- 

// Initialize all records 

// - 

for (1 = 0; i < estates; i++, pastate++) 

{ 

//- 

// Initialize the container record control structure 

//- 

precord->RecordCore.cb = sizeof (MINIRECORDCORE); 

//- 

// Copy our data to the container record control struct 

//- 

precord->RecordCore.pszIcon = pastate->pszState; 
precord->pszCapital = pastate->pszCapital; 

precord->ulPopulation = pastate->ulPopulation; 

precord->cdateAdmitted.month = pastate->ourdateAdm.mm; 
precord->cdateAdmitted.day = pastate->ourdateAdm.dd; 
precord->cdateAdmitted.year = pastate->ourdateAdm.yy; 

// Move to next record 

precord * (PRECORD) precord->RecordCore.preccNextRecord; 

J 
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//- 

// Construct record insertion control structure 
//-- 


memset (&recordlnsert, 0, sizeof (RECORDINSERT)); 


recordlnsert.cb 
recordlnsert.pRecordParent 
recordlnsert.pRecordOrder 

recordlnsert.zOrder 
recordlnsert.cRecordsInsert 
recordlnsert.fInvalidateRecord 


-sizeof (RECORDINSERT); 

= NULL; 

- (PRECORDCORE)((ULONG) 

MPFROMSHORT(CMA_END)); 

- (USHORT) CMA_TOP; 

= estates; 

- TRUE; 


tt - 

// Insert the records 
it - 


WinSendDlgltemMsg (hwndDlg, idContainer, 
CM_INSERTRECORD, 

MPFROMP (precordFirst), 
MPFROMP (firecordlnsert)); 


//--- 

// Return to caller 
tt - 

return 0; 

1 


LISTING 2. CNFUNC.C 


if (WinLoadString (hab, hmod, usStringID, MAXMSGSIZE, 
pszBuf) == 0) 

{ 

free (pszBuf); 
return (NULL); 

} 

return (pszBuf); // Return -> string 

) 


//- 

it 

t / CnCreateDetailsView 

tt 

It Create the details view of the container. This requires 

ft setting up the column information. 

it 

tt - 


USHORT 

CnCreateDetailsView ( 

// 

Create details view 

HWND 

hwndContainer, 

tt 

I - container window 

USHORT 

cColumns, 

It 

I - Number of colums 

COLDESC 

acd(], 

tt 

IO->column descriptor 

SHORT 

sLastLeftColumn, 

tt 

I - Last column in 



tt 

left split window 



tt 

-1 means no split 

LONG 

IPetSplitBarPos, 

tt 

Percent of entr width 



ft 

to set split bar 

USHORT 

idTitle, 

tt 

I - container hdg id 

HMODULE 

hmod) 

tt 

I -hmod for resources 

USHORT i; 

tt 

Loop counter 


// cnfunc.c - Container utility functions 


// - 

ft 

ft cnfunc.c 

ft 

it Container utility functions 

ft 

tt - 


CNRINFO 

enrinfo; 

tt 

Cntr info structure 

PFIELDINFO 

pFieldlnfoHead; 

ft 

-> First field 

PFIELDINFO 

pFieldlnfo; 

tt 

-> Current field 

FIELDINFOINSERT FieldlnsertInfo; 



PCOLDESC 

ped; 

tt 

Column descriptor 


//- 

ft Get container text information 
ft - 


#define INCL_WIN 
♦include <os2.h> 

♦include <stdlib.h> 
♦include <string.h> 

♦include "enfunc.h" 


for (ped - acd, i - 0 

{ 

if (pcd->pszTitle 
pcd->pszTitle 


) 


i < cColumns; i++, pcd++) 

“ NULL) 

- UtilLoadString (pcd->idTitle, 

WinQueryAnchorBlock (hwndContainer), 
hmod); 


♦define MAXMSGSIZE 255 


ft Max size of string 


tt - 

It UtilLoadString - load a string from the resource file 

// - 


tt - 

t/ Initialize the container for a simple details view 

// - 

memset (Scnrinfo, 0/ sizeof(CNRINFO)); 
cnrinfo.cb = sizeof (CNRINFO); 


PSZ UtilLoadString ( ft 

USHORT usStringID, ft 

HAB hab, tt 

HMODULE hmod) // 

I 

PSZ pszBuf; // 


pszBuf = malloc (MAXMSGSIZE); 


Load string from res 
I - String identifier 
I - Current HAB 
I - Resource module or NULL 

String buffer 


tt Set for Details View, with column titles, with icons and 
tt not bitmaps, include a container title, with a separator 
tt bar underneath it, and don't let the user change title 
enrinfo.flWindowAttr - CV_DETAIL | 

CA_DETAILSVIEWTITLES | 
CA_CONTAINERTITLE | 

CAJTITLESEPARATOR; 
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cnrinfo.pszCnrTitle = UtilLoadString (idTitle, 

WinQueryAnchorBlock (hwndContainer), 
hmod); 

WinSendMsg (hwndContainer, CM_SETCNRINFO, 

MPFROMP (scnrinfo), 

MPFROMLONG (CMA_FLWINDOWATTR | CMA_CNRTITLE)); 


//- 

WinSendMsg (hwndContainer, CM_INSERTDETAILFIELDINFO, 
MPFROMP (pFieldlnfoHead), 

MPFROMP (SFieldlnsertInfo)); 

return 0; 

) 


//- 

// Get memory for the column information 
//- 

pFieldlnfoHead = (PFIELDINFO) PVOIDFROMMR ( 

WinSendMsg (hwndContainer, 

CM_ALLOCDETAILFIELDINFO, 
MPFROMSHORT (cColumns), 
0 ) ) ? 

pFieldlnfo - pFieldlnfoHead; // Start at top of list 


// - 

// Load the field info structures 
U - 


for (pcd « acd, i * 0; 

( 

pFieldInfo->cb 
pFieldlnfo->fIData 
pFieldInfo->flTitle 
pFieldInfo->pTitleData 
pFieldlnfo->offStruct 
pFieldInfo->pUserData 
pFieldInfo->cxWidth 


i < cColumns; i++, pcd++) 

sizeof (FIELDINFO); 
pcd->f1Attributes; 
pcd->flTitle; 
pcd->pszTitle; 
pcd->offField; 

NULL; 

pcd->cxWidth; 


if (sLastLeftColumn >= 0) 

{ 

if (sLastLeftColumn == i) 

{ 

SWP swp; 

WinQueryWindowPos (hwndContainer, &swp); 
cnrinfo.pFieldlnfoLast - pFieldlnfo; 
cnrinfo.xVertSplitbar * 

(swp.cx * IPetSplitBarPos) / 100; 
WinSendMsg (hwndContainer, CM_SETCNRINFO, 

MPFROMP (scnrinfo), 

MPFROMLONG (CMA_PFIELDINFOLAST | 
CMA_XVERTSPLITBAR)); 

} 

} 

pFieldlnfo * pFieldInfo->pNextFieldInfo; 


//- 

// 

// CnDestroyDetailsView 

// 

// Destroy the details view of the container. This 

(/ requires freeing column information. 

// 

//- 


USHORT CnDestroyDetailsView ( 

// 

Destroy details view 

HWND hwndContainer, 

// 

I - Handle to cntr window 

USHORT cColumns, 

// 

I - Number of colums 

COLDESC acd(]) 

/ 


// 

IO—> column descriptor 

1 

USHORT 

i; 

// 

Loop counter 

PCOLDESC 

pcd; 

// 

Column descriptor entry 

CNRINFO 

cnrinfo; 

// 

Container info structure 


//- 

// Remove any column titles loaded into memory 

//- 

for (pcd *= acd, i * 0; i < cColumns; i++, pcd++) 

( 

if ( (pcd->pszTitle !- NULL) 

&& (pcd->idTitle != 0) ) 

I 

free (pcd->pszTitle); 
pcd->pszTitle = NULL; 

* 

} 

//- 

f / Remove the column heading from memory 

//--- 

WinSendMsg (hwndContainer, 

CM_QUERYCNRINFO, 

MPFROMP(Scnrinfo), 

MPFROMSHORT (sizeof(CNRINFO))); 


//- 

// Construct the FIELDINFOINSERT structure that describes 
// the number of fields to be inserted, where they are to 
// be inserted, etc. 

//- 


free (cnrinfo.pszCnrTitle); 


H - 

If Remove the column information of the container 

//- 


memset (&FieldInsertInfo, 0, sizeof(FIELDINFOINSERT)); 
Fieldlnsertlnfo.cb =*= sizeof (FIELDINFOINSERT); 

Fieldlnsertlnfo.pFieldlnfoOrder = (PFIELDINFO) CMA_END; 
Fieldlnsertlnfo.cFieldlnfoInsert « cColumns; 

Fieldlnsertlnfo.fInvalidateFieldlnfo » TRUE; 


WinSendMsg (hwndContainer, 

CM_REMOVEDETAILFIELDINFO, 

0 , 

MPFROM2SHORT (0, CMA_FREE)); 


//- 

// Insert the fields. 


//- 

t/ Remove any records in the container 
//- 
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WinSendMsg (hwndContainer, 

CM_REMOVERECORD, 

0 , 

MPFROM2SHORT (0, CMA_FREE)) 

return 0; 


LISTING 3. CNRDTL.H 


// cnrdtl.h — Definitions for cnrdtl demo 


//- 

// Change the following as required for target system 

ft - 


♦define OS220 
//♦define OS2I3 

♦ifdef OS220 

♦define MSGID ULONG 
♦else 

♦define MSGID USHOR 
♦include <fclcnrp.h> 


// Define target system 
// OS/2 1.3 + CUA Lib/2 


// OS/2 2.0 


// OS/2 1.3 
// CUA Library/2 


♦define WC_CONTAINER 

CCL_CONTAINER // Window class 

BEGIN 


♦endif 



IDS_HEAD_STATE, 

"\Q12State" 




IDS_HEAD_CAP, 

"\012Capital" 

// Defines for dialogs. 

controls 

IDS_HEAD_POP, 

"Population\012(1980 Census)" 

♦define 

IDLG_EXAMPLE 

100 

IDS_HEAD_ADM, 

"Entered\012Union" 

♦define 

IDCN_STATEINFO 

200 

IDS_TITLE, 

"State Information Table\012(1987 Almanac)" 

♦define 

IDS_HEAD_STATE 

500 

END 


♦define 

ID S_HEAD_CAP 

501 



♦define 

IDS_HEAD_POP 

502 

DLGTEMPLATE IDLG_ 

EXAMPLE LOADONCALL MOVEABLE DISCARDABLE 

♦define 

IDS_HEAD_ADM 

503 

BEGIN 


♦define 

IDS_TITLE 

504 

DIALOG "State 

Information", IDLG_EXAMPLE, 40, 27, 200, 150, 


LISTING 4. CNFUNC.H 


// cnfunc.h — Container utility functions 


//- 

// 

// cnfunc.h 

// 

// Container Functions 

// 

//- 


li¬ 

lt 

//- 


Data structure used to describe field information 


typedef struct 

// 

Field (column) descriptors 


{ 

ULONG 

of fField; 

// 

Offset of field in record 

♦ Make File Creation run in 

♦ D:\P\MAGAZINE\CNRDTL; 

ULONG 

flAttributes; 

// 

Field attributes 


USHORT 

idTitle; 

// 

Identifier of column title 

.SUFFIXES: 

ULONG 

flTitle; 

// 

Title Attributes 


USHORT 

cxWidth; 

// 

Column width (0 = auto calc) 

.SUFFIXES: .c .rc 

PSZ 

pszTitle; 

// 

Pointer to column title text 


} COLDESC, 

♦PCOLDESC;- 



ALL: CNRDTL.EXE \ 

CNRDTL.RES 


// Function prototypes 
//- 


USHORT CnCreateDetailsView ( 
HWND hwndContainer, 

USHORT cColumns, 

COLDESC acd[], 

SHORT sLastLeftColumn, 

LONG lPctSplitBarPos, 
USHORT idTitle, 

HMODULE hmod); 

USHORT CnDestroyDetailsView ( 
HWND hwndContainer, 

USHORT cColumns, 

COLDESC acd[]); 


LISTING 5. CNRDTL.RC 


♦include <os2.h> 
♦include "cnrdtl.h" 


// Create details view 

//I - Handle to container window 

//I - Number of colums 

// 10—> column descriptor 

//I - Last column in left split 

// Percent of container width 

//I - container heading id 

// I - handle to resource file 

// Destroy details view 

//I - Handle to container window 

//I - Number of colums 

// IO—> column descriptor 


// OS/2 definitions 
// Application defs 


STRINGTABLE 


WS_VISIBLE, FCF_SYSMENU | FCF_TITLEBAR 

BEGIN 

CONTROL IDCN_STATEINFO, 

20, 31, 160, 110, WC_CONTAINER, 

CCS_SINGLESEL | CCS_READONLY | 
CCS_MINIRECORDCORE | 

WS_GROUP | WS_TABSTOP | WS_VISIBLE 
PRESPARAMS PP_FONTNAMESIZE,"8.Helv\0" 


GROUPBOX 


300, 19, 30, 162, 116 


DEFPUSHBUTTON "OK", DID_OK, 15, 9, 48, 13, WS_GROUP 

PUSHBUTTON "Cancel", DID_CANCEL, 78, 9, 48, 13, 

NOT WS_TABSTOP 

END 

END 


LISTING 6. CNRDTL.MAK 
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INTRODUCING CONTAINERS 


cnrdtl.exe: \ 


CNFUNC.OBJ \ 


CNRDTL.OBJ \ 

# Make File Creation run in directory: 

CNRDTL.RES \ 

# D:\P\MAGAZINE\CNRDTL; 

CNRDTL.MAK 


@REM @<<CNRDTL.@0 

# Assumed INCLUDE environment variable path: 

/CO /M /NOL /PM:PM + 

# C:\TOOLKT20\C\OS2H? 

CNFUNC.OBJ + 

# C:\TOOLKT20\ASM\OS2INC; 

CNRDTL.OBJ 

# C:\IBMC\INCLUDE; 

cnrdtl.exe 

# E:\GPF\INCLUDE; 


CNRDTL.RES: CNRDTL.RC \ 

« 

# {.;$ (INCLUDE) )OS2.H V 

LINK386.EXE @CNRDTL.@0 

{.,•${ INCLUDE)) CNRDTL. H \ 

RC CNRDTL.RES cnrdtl.exe 

# {.;$(INCLUDE)JFCLCNRP.H \ 


CNRDTL.MAK 

{.}.rc.res: 


RC -r .\$ *.RC 

CNFUNC.OBJ: CNFUNC.C \ 


# {$(INCLUDE);)os2.h \ 

{.}.c.obj: 

# {$(INCLUDE);)stdlib.h \ 

ICC.EXE /Ss /Kbger /Ti /W2 /C .\$*.c 

# {$(INCLUDE);}string.h \ 


{.;$(INCLUDE);)cnfunc.h \ 

Jinclude CNRDTL.DEP 

CNRDTL.MAK 


CNRDTL.OBJ: CNRDTL.C \ 


# {$(INCLUDE);)os2.h \ 

LISTING 7. CNRDTL.DEP 

# {$(INCLUDE);)stdlib.h \ 


# ($(INCLUDE);}s tdde f.h \ 


'*m BackMaster 






wm&i 


53 

Backup g**tof* 


SI? I 

40.448 ■ 4 - 10 - 133 ? 


4S??Sf 
12 4.MO 


DPiOPif.FOtOI 




OS/2 2.0 32-Bit PM Based 

Backup Utility. 


Supports FAT, HPFS, Long Names, and Extended Attributes 
Variable Data Compression, Printed and On-Line Documentation. 
Backup/Restore to Floppies and QIC-40/80 floppy Tape Drives! 
Incremental Backups: Wildcards, Time/Date, & Graphical Selection 
We Support CMS JUMBO Tape Drives. 

Unattended / Delayed Operation.. 

Runs Transparently in the Background. 

Exploits Multithreading for better performance. 

List Price $79.95, Special $49.95 + $5.00 Shipping until Dec 25. 
Texas Residents add 7% Sales Tax ($3.49). 

For More Information Call or leave a message on our support BBS. 
Call our 24 Hour Support BBS 2400-14,400bps, for Demo Version. 
To Order; Call, or Send Check, money order, VISA/MC to: 


MSR 


Development 


Rt 7 #6409 Nacogdoches Tx, 75961 

Ph (409) 564-1862 — BBS (409) 560-5970 
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PAINT BY NUMBERS 

THE ULTIMATE OS/2 GAME 


Timur 

Tabi 


Timur Tabi can be 
reached at 2 Lloyd Haven 
Drive; Huntington, NY 11743. 
Source code is available on 
the OS/2 Shareware BBS, 
703-385-4325. 


I love writing this column. Not only do I look 
forward to actually playing this game once it’s 
done, but I like contributing to something in 
which I strongly believe, and I really do believe 
that OS/2 is the wave of the future. 

Time constraints have prevented me from 
adding as much as I promised last month. The 
only new enhancements you will find are the im¬ 
plementation of dialog boxes for the “Map” 
menu items. Do not underestimate the amount of 
work required to support these features, howev¬ 
er. A whole module was added for the load and 
save routines. The basic skeleton of the code 
comes from Petzold’s book, an antiquated yet 
still valuable resource. 

The dialog boxes themselves are created with 
the Dialog Box Editor that comes with the tool 
kit. The editor creates a .dig, a .res, and a .h file. 
The .dig file contains the resource script com¬ 
mands that define the dialog boxes. The .res file 
is a compiled version of the .dig file. 

There are a few things that should be kept in 
mind. First, do not include .res file as a module 



in the make file because the resource compiler 
(rc) cannot combine individual resources. Every 
time rc links a resource file into the executable, it 
replaces the existing resources with those in the 
.res file. If you want to include several types of 
resources, then you must create a master re¬ 
source script file which contains “rcinclude” 
statements. This process will create a single .res 
file containing all your resources. 

Secondly, beware of errors in the online help 
for the tool kit. The only way to be certain of the 
information is to check the header files. An ex¬ 
ample is the structure definition for FILEFIND- 
BUF3. Compare this with the entry in bsedos.h 
and you will see what I mean. 

Last of all, double-check all the parameters 
when using code designed for OS/2 1.x. Most of 
the 16-bit integer parameters are now 32 bits 
long. Note that there is no speed difference be¬ 
tween short and long integers on a true 386/486 
system, since the 32-bit wide data bus can swal¬ 
low both sizes in one gulp. 

Look at the file game.rc, which is the master 
resource file for this project. It includes the 
dialog.dig file that the editor creates. Note 
that both files include dialog.h - the header 
file also created by the dialog editor. 1 am 
not sure why this is necessary, but hopefully 
an explanation will present itself in due time. 

The dialog box for loading and saving 
files follows a convention that exists in most 
applications. The two list-boxes show a list 
of directories and a list of files in the current 
directory and an entry field allows you to 
type in a file or path name. Selecting a file 
from the list-box places that name in the en¬ 
try field automatically. Once you have select¬ 
ed a file, click on “Save” to save the current 
map to that file, or click on “Load” to load 
that file. The current implementation is not 
100% complete. The load and save option 
should not be combined, and there is no 
check for overwriting an existing file. These 
changes will be available in the next install¬ 
ment. 

The code for controlling both list-boxes is 
in the file files.c, which will eventually be¬ 
come a module of generic file I/O routines. 
The fill-functions for the list-boxes are very 
similar. Any existing entries are erased and 
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the new entries are determined by scanning 
the current drive and directory. You may 
notice that the list-boxes are extra wide. 
This allows most HPFS long filenames to be 
displayed in their entirety. I only wish that 
my other applications worked the same 
way. As with everything else in this project, 
the dimensions of the dialog box can be 
changed with the editor to suit your prefer¬ 
ences. Those of you with high resolution 
monitors and tiny system fonts will proba¬ 
bly want to increase the size even further. 

Notice that the DosFindFirst/Next func¬ 
tions ignore any extended attributes. The 
map files will eventually be given a file type 
(a.k.a. association) that will distinguish 
them from other files without needing a 
special extension. The short-term goal of 
this project is to bring the game up and run¬ 
ning as quickly as possible, so that no one 
has to wait until 1994 before he can play. 
Note that I did not say 1993. Sorry folks, but 
this thing will not be done before Christmas 
— it should be ready by spring. 

My roommate Scott and I got into a dis¬ 


cussion over the importance and design of 
a user interface. We ended up agreeing on 
almost everything, but the differences be¬ 
tween the programmer (me) and the user 
(Scott) became very apparent. Scott argued 
that the UI should be designed and coded 
at the same time as the rest of the program. 
His concern was that leaving the interface 
until later would cause inconsistencies be¬ 
tween the interface and the application. I 
had to agree with him on this point, but I 
also had to mention that trying to create 
both at the same time causes most program¬ 
mers to bite off more than they can chew. 

Frankly, I think that attempting to fully 
design an application, interface and all, be¬ 
fore any coding is started is a pipe dream 
that only works with software devoid of 
creativity. Remember, this game cannot be 
designed beforehand because it is a group 
project. New ideas and changes occur con¬ 
stantly, so the primary goal for the present 
is not to design a complete user interface, 
but rather a flexible one. What does that 
mean, you ask? It means that the applica¬ 


tion should not be designed with only one 
“look-and-feel” in mind. 

In other words, there is more than one 
way to skin a cat, just as there is more than 
one way to create a playing field. Pull-down 
menus allowed me to create a map editor 
which worked without wasting too much 
time on the code. Had I taken the time to 
create something more sophisticated, it 
would have been vastly more time-consum¬ 
ing to modify the more complicated code. 
And that is only the short-term problem. In 
the long run, we would probably end up 
with a user interface which no longer suited 
the task at hand. Therefore, our approach 
will be to formulate an interface which ex¬ 
pands along with each new feature. 

This, in a nutshell, is my philosophy on 
user interface design. I will be very happy 
to entertain any comments on the subject. 
Scott, by the way, is responsible for the 
new icon, which is much better than the 
one I designed. If anyone thinks he or she 
can do a better job, feel free to submit your 
creativity. ♦ 


OS/2 "BATCH MANAGER" 


TO SUBMIT, MONITOR AND CONTROL BATCH JOBS 



Start 

Start Date Time Status 


Single/ 


Job 

ID Job Name 


, Ji*lL 


WORK ORDERS 


X:\COMMAND\ORDER.CMD 


STARTUP.CMD 


19920422 


Every Other Day 
Sunday 


JOB SUBMISSION 


BATCHQ1 

11 SALES ORDERS 

7 Daily DTL upgrade 

9 DAILY BACKUP 

8 PAYROLL 


Active 

04-22-1992 08:32 Active S 
04-23-1992 07:00 Delayed R 
04-22-1992 23:30 Delayed R 
04-30-1992 12:00 Delayed R 


CUA COMPLIANT 
$100 PER OS/2 WORKSTATION 
For Information or To Order, Contact: 


M. BRYCE & ASSOCIATES, INC. 
777 Alderman Road 
Palm Harbor, FL 34683 
Tel: 813/786-4567 
Fax: 813/786-4765 
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BUILDING PROGRAMS 


OBJECT OBJECTIVE 


David 

Moskowitz 


David Moskowitz is 
president of Productivity 
Solutions, 164 Avondale 
Road, Norristown PA 
19403-2952. The consulting 
firm specializes in OS/2 and 
object oriented develop¬ 
ment He is the author of 
Converting Applications to 
OS/2, Brady Books, * 1989, 
and the forthcoming revi¬ 
sion. He can be reached on 
CompuServe at 76701,100, on 
MClMail at 341-4084. 


If you’ve read the past articles in this series, you 
know we’ve devoted lots of space to a discus¬ 
sion about what an object is and why it makes 
sense to consider changing your development 
model to use an object-oriented approach. We’ve 
discussed the need to develop a different mind¬ 
set for object-oriented development compared to 
classic procedural development. In addition, 
we’ve talked about OOP being an iterative 
process. There are a couple of conclusions that 
might not be obvious if you take these ideas to 
their extremes. 

When we build object-oriented programs, 
very often we aren’t really building programs, 
per se. Instead, we define objects and build the 
functionality of the completed program by ar¬ 
ranging for objects to collaborate with each oth¬ 
er. In an object-oriented development environ¬ 
ment, rather than think about the final 
completed program, we concentrate first on 
building objects that can be re-used. Ap¬ 
plications are really objects combined to pro¬ 
duce results. 

In procedural code, we build applications out 
of cooperating functions. We use that knowledge 
when we design and build systems. For example, 
we know the calling conventions of the public 
functions. Sometimes, we might even know 
something about the data structures used by the 
functions. (It is interesting that ever since David 
Parnas’s article “On The Criteria to bei Used in 
Decomposing Systems into Modules,” appeared 
in the Communications of the ACM in December 
1972, we’ve had formal “proof” about the prob¬ 
lems associated with an approach to develop¬ 
ment that ignQres hiding implementation details. 
If you look at code, today, you can still see glob¬ 
al data, etc). 

Object oriented design 

We build object-oriented applications out of col¬ 
laborating objects. Each object has its own set of 
responsibilities. The object’s responsibilities are 
encapsulated with the class definition. Each ob¬ 
ject has a defined set of behaviors. Further, the 
only thing one object “knows” about another 
object is the operations that the other object can 
be requested to perform. 

To put it another way, an object only knows 
about the messages it can send to other objects. 


Messages are requests that an object respond. 
The requesting object does not know, nor does it 
care how the request is handled. 

The published list of operations defines the 
responsibilities of a class of objects. As we de¬ 
sign object-oriented applications, our first step is 
to identify the objects. As we identify objects, 
we also have to define the responsibilities or 
behaviors. 

During the early stages of object-oriented de¬ 
sign, we are less concerned about “how” any 
particular class of object will behave. Instead we 
concentrate on “what” the object does. 

This level of abstraction is important. During 
the initial stages, we are not concerned with the 
internal logic that defines “how” the object be¬ 
haves. Instead we concentrate on a definition of 
what the object can do, what responsibilities the 
object has and what services it may require from 
other objects. 

Once we’ve identified an object, we decide 
what behavior other objects will require of this 
object (its responsibilities). The actual logic or in¬ 
ternal behavior encapsulated (or hidden) within 
the object, itself. The process of object-oriented 
design is, in part, based upon the difference be¬ 
tween the public information about the behavior 
of the object and the internal private logic that 
makes it work. 

Basically, object-oriented design means we 
have three tasks. First, we have to identify the 
objects. Fundamentally, this can be viewed as an 
English exercise. Find the nouns or noun phras¬ 
es in the specification and assume that as a start¬ 
ing point for object recognition. (We group the 
objects by similarities and differences that this 
helps us identify classes.) 

Once we have the list of object candidates, we 
turn our attention to object behavior. We use the 
behavior of the objects to build the conceptual 
model of the application. It is the object’s behav¬ 
ior that we map to become the responsibilities of 
the object. We ask ourselves, “What steps, ac¬ 
tions, or results does this object produce?” Notice, 
this is a “what” question, not a “how” question. 

After we’ve identified the objects, and respon¬ 
sibilities, we begin to ask which objects handle 
which tasks. Which other objects are necessary 
to complete the given, “Assignment?” 

A line from an old Jefferson Starship song was 
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true about people and true about objects, “No man is an island, 
he's a peninsula.” No one object will provide all the responsibili¬ 
ties necessary to completely map a complex application. Objects 
collaborate with each other; or, if you will, they delegate responsi¬ 
bilities to other objects. 

So, the next phase of object-oriented design is to identify what 
this object needs from other objects, and which other objects (or 
collaborators) must be part of the system. 

In effect, we define the public interface that “documents” the 
responsibilities this object accepts. Based upon this knowledge, we 
can select other objects to collaborate with this object to accom¬ 
plish a specific function. 

CRC 

There is a name given to this approach of object-oriented design 
— CRC cards. CRC cards are standard lined index cards (either 3 
by 5 or 4 by 6 depending upon how small you write, or how much 
you want to put on a card). CRC stands for Class, Responsibilities, 
and Collaborations. 

Draw a line about one-third the horizontal distance from the 
right (on a 4 by 6 card, draw a line 4 inches from the left side). Put 
the name of the class on the top line of the left hand side of the 
card. Use the left hand two thirds for the responsibilities of the 
class (and object members of the class). In the right third, place the 
collaborating classes (or objects). 


That's it — one class per card. It doesn’t make any difference 
how many cards you have. It is better to have too many classes 
than two few; it is easier to prune things you don’t need than it is 
to add things you’ve forgotten. 

If something comes up either in discussions with co- workers 
on during your own work with the problem, you can always add 
a class. (CRC cards can be passed around a small implementation 
group for comment, review, etc.) Similarly, you can discard cards 
that no longer seem appropriate in whatever new context evolves 
as you work. 

Don't just stand there.... 

Once you have a start on design, begin to implement the classes. 
Don’t wait until the design is completed before you start imple¬ 
mentation (i.e., building objects). Object-oriented development en¬ 
courages the design a little code a little approach. The only way 
you’ll get comfortable with the methodology is to use it. 

Object oriented development also allows us to make mistakes. 
We always learn more about a system as we play with it. We al¬ 
ways see things we could have improved or will improve next 
time. Object-oriented development is the way around the old clas¬ 
sic way to create systems — “Build the whole, thing, push it off a 
cliff, watch it crash, and start all over.” (I’ve heard this referred to 
as the Wright Brothers approach. However, Orville and Wilbur 
didn’t do that.) 


P-s-s-t ! 


no need to tell anyone 
you have CommandLine. 


Tell your friends you aren't fazed by all the 
icon clutter - "Icons! Love 'em! nothing 
like a little Shredder Action ... Mouse freak? 
Hey, I wish they made a POUR button mouse! 
Don't know why they call it a Workplace; it's 
a fun place to me". And with CommandLine, 
it certainly will be! 



Intelligent Application Launching with: 

- Hotkey Application Start, Bait Switch 

- Command Aliasing & History 

- Inline Pile Find & Filename Completion 

- Alternate Command Shell Support 
* Rexx Expression Interpretation 

- Instant WPS Object Creation 

- Active Window Toggle 

- Ideal for portables 



95 


Because APIs DO fail . . . 

We all know that Toolkit APIs fail. So that you 
don't have to check every call. Error Manager 
does. EM tells you which API failed, where it 
failed and why. EM can log all errors to a file 
or pipe, and optionally notifies your window 
procedure enabling centralized error processing. 

32-bit 
Version 2.0 
for OS/2 2.0 




- Invaluable for Debug, Test and Production cycles. 

- Finds intermitent errors without the Debug Kernel. 

- Includes pointer validity subroutine. 

- Requires no assembly knowledge. 

- Works with Optimized code. ... *725 


Include 1 header file. 

Link 1 DLL. 

Set 1 environment variable. 


Introductory Price: 

$175 




2224 East 21st Street 
Brooklyn, New York 11229 


(718) 769-8017 


* Plus $5 Shipping & Handling. MY State residents must add sales tax. 
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The development loop 

The key point about object-oriented development is that it does 
not progress in neat, nicely-bound stages. It is an iterative process. 
If you discover you need a new object, add it. If you picked an in¬ 
correct object, discard it. If you didn’t get it exactly right, change 
it. 

Object-oriented development supports change in a way that is 
very different from classic structured programming. Object-orient¬ 
ed development encourages change as we learn more about the 
system and its needs. Using structured programming, we had to 
specifically design change points into the code. We had to docu¬ 
ment all the interactions (well, that was the idea, on a large project 
(i.e., more than three to five people) trying to document the de¬ 
pendencies either never happened, was incomplete, or wasn’t kept 
up to date). 

Using an object-oriented approach to design empowers us to 
make mistakes, to make changes, to start with something that 
works and grows, to learn more about the system as we build it. 
This is the real power of object-oriented development. As we de¬ 
sign object-oriented systems, we use the inherent isolation of each 
object to our advantage. Since the only thing published about an 
object is what it does, we are free to change the internal represen¬ 
tations, fix bugs and extend the objects’ capabilities without any 
risk of introducing bugs in other parts of the system because of in¬ 
teraction. In fact, it is this lack of side effects of changes that is an¬ 
other way of describing object re-use. 

Client-Server revisited 

One last point, when we talk about collaboration in the object-ori¬ 
ented world, we aren’t talking about anything new or totally 
unique to OOP. For over three years, we’ve been telling develop¬ 
ers to use the client-server model to build single user OS/2 appli¬ 
cations. 

The usual context for the discussions revolved around the use 
of OS/2 dynamic link libraries (DLLs). The object, was to recognize 
that at any point in time, any given DLL could be a server to one 
section of code and a client of another. A DLL isn’t always intend¬ 
ed to be a “server” or a “client.” Instead, client and server are roles 
that dynamically change while the program runs. 

In an object-oriented world, we still use the client server con¬ 
cept. A collaborating object may be a server to the requesting ob¬ 
ject. At the same time, it can be a client to a third object. We don’t 
have to assign a DLL to be either a client or a server. However, the 
relationship between client and server is important. 

If it proves helpful, you can visualize client-server as if a net¬ 
work is involved. The client makes a request of the server, over 
the network. The client cannot get access to anything the server 
doesn’t explicitly send to him since the two are running in two 
separate computers. You can think of object collaboration in this 
way, whether or not a network is involved. 

Coming attractions 

Next month we’ll take look at design a bit more. In addition, we’ll 
also begin to talk about picking object-oriented tools and lan¬ 
guages. 


Windows, OS/2 & Unix 


Consultants Programmers Systems Analysts 




800-862-2211 
Ext. 50 # 


Technologies, Inc. 

We provide on/off site consultants and 
programmers for short or long term 
assignments, who are specialists in, 
but not limited to, application design 
and development in the following 
areas: 


Microsoft Windows 

4 

Presentation Manager 

1 

Communication Manager 


Database Manager 


LAN Manager 


X-Windows 


UNIX Communications 

♦ 


Some of the services we can provide you with: 


Product Planning 
Cost Analysis and Projections 
Project Leadership and Management 
Requirement Analysis 
Functional Specifications 
SAA/CUA Application Design 
System Testing and Verification 
System Design and Development 
Host Front-end Design 



Come to us first when you need 
software engineers to design, code and 
implement your Microsoft Windows, 
OS/2 and Unix applications. 

Ceres Technologies, Inc. 

8903 Glades Road Suite L-9234 Boca Raton, FL 33434-4021 
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IN THE TRENCHES 


T o NT, or not NT, that is the ques¬ 
tion. .. Whether ’tis nobler to suffer 
the slings and arrows of outrageous 
propaganda.... When I hear people talk 
about Microsoft’s NT operating system, my 
first response is “What new technology?”. 
NT is based largely on the Mach kernal, and 
having OS/2 source code taught the boys 
from Redmond a lot. Oh, sure, there’s some 
neat new file system stuff, but to hear it tell 
from the Windows bigots, NT is a revolu¬ 
tion that is so much better than anything 
else out there. I guess these guys have nev¬ 
er heard of Unix. 

But the really amazing part of all this is 
how these guys compare NT’s proposed 
features with what OS/2 has now. I have 
news for all those who wait with baited 
breath for NT. It’s going to be late. Like 
2Q93 late (although the ‘Softies are proba¬ 
bly aiming for Spring COMDEX in May). 

How concerned is MS about bugs and 
problems? Well, they’re even thinking of 
calling the OS Windows NT 3.1. Now I 
don’t know about you, but anyone who 
would be taken in by such a stupid ploy 
deserves what they get. Like the fact that 
there are whole classes of software that will 
not work under NT (those that access the 
hardware directly). 

NT was originally designed as a server 
OS, which is why the security issue is so 
important. People expecting to run all their 
DOS apps without changes are going to be 
in for a rude shock. Further, NT’s micro-ker- 
nal approach is less speedy that a tradition¬ 
al OS like OS/2. Of course, MS wants you 
to run NT on fast CPUs anyway, like RISC 
machines. OS/2’s superior DOS compatibili¬ 
ty is a strong reason why it is so popular. 
NT’s DOS compatibility will be weaker, thus 
hurting its chances in the retail channel. 

Windows bigots do not understand that 
the competition for OS/2 2.0 is not NT, it is 
DOS/Windows. MS does not plan to put NT 
on every desktop (not every machine has 
the oomph for NT). And IBM does plan to 
make their own microkernel based version 
of OS/2 (called Portable OS/2). And unlike 
MS, IBM is using its existing software and 
expertise (in conjunction with Carnegie 
Mellon University) to provide a new prod¬ 
uct. MS wants to re-invent the wheel, it 


seems. Most likely Portable OS/2 will be 
merged with IBM’s AIX (Unix-based) prod¬ 
uct. Look for an announcement on this at 
Fall COMDEX. 

Consider the Win32 and Win32s APIs. 
Why are so many rushing to develop for 
NT, which hasn’t proved it can sell worth a 
damn? To take advantage of NT, you have 
to make a program that runs only on it. If 
you make a 32 bit Win32s program to be 
compatible with Win 3.1, it will be creamed 
on NT by its feature-rich competitors. I 
think these developers are being suckered 
into making software for an unproven mar¬ 
ket so MS can hype up NT applications 
availability. 

Me, I believe you should develop for ex¬ 
isting markets fist, then developing markets 



second. Right now, with over a million 
copies of OS/2 being sold, this is where the 
action currently is. And if porting to NT is 
as easy as they say, it makes sense to wait 
until NT takes off (assuming it does). 

But there is an even more crucial prob¬ 
lem facing Microsoft and NT: the issue of 
support. If NT is to be a server OS, and is 
to make it in the Fortune 500 world, it will 
have to provide support. This means 24 
hour a day, worldwide support for its prod¬ 
uct. And frankly, MS doesn’t have the 
oomph to do it. One thing abut IBM’s 
bloated bureaucracy, there is an office al¬ 
most everywhere you go. 


I think NT will find some acceptance, 
but it will never achieve the market pene¬ 
tration that OS/2 does. New users of 486 
machines might go for it. And of course, 
the die-hard Windows bigots. But to listen 
to the Windows crowd, they seem to think 
that NT will make OS/2 dry up and go 
away. Sorry, Bill. 

By the time NT ships, OS/2 will have 
had a lot of bug-fixing and cleaning up, as 
well as the necessary drivers (about time!) 
for video cards and other peripherals. 
Further, there will be a host of 32 bit OS/2 
apps from companies like Lotus, Borland, 
and WordPerfect. When NT does hit the 
streets, their users will have to go through 
the same painful process of waiting for bug 
fixes, applications and so on that we OS/2 
users have had to put up with. By the time 
the end of 1993 rolls around, NT will have 
finally started to pick up steam. But OS/2 
will have had over a year long head start. 

Finally, it’s easy to show the advantages 
of 32 bit OS/2 vs 16 bit Windows to users. 
Try selling an end user on the idea of hav¬ 
ing C2 security. This is something for LAN 
administrators. 

Now, I’m not saying NT will be a disas¬ 
ter. It will have its place, just as OS/2 and 
Windows 3-1 will. But for now and the 
foreseeable future, the OS of choice will 
continue to be DOS for the majority of 
users. New users with powerful machines 
will probably not choose a DOS-only plat¬ 
form, but there are still a lot of 286 and XT 
boxes out there. Eventually, though, I be¬ 
lieve OS/2 will grab a larger market share 
that Windows (whatever flavor). Of course, 
this assumes that IBM actually wakes up 
and listens to its customers about how to 
market and improve its product. If not, 
well, the game 
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MITNOR Software 
28411 E. 55th Street 
Broken Arrow, OK 74014 

Phone: (918) 357-1628 
Fax: (918) 357-2869 


TO * mu 



PrntScrn™ is THE One-Step Screen Image Utility 
for copying a graphics image from the Workplace 
Shell screen to a LAN or locally attached printer, to 
the Clipboard, or to a disk file. The screen images 
appearing in this publication were captured and 
processed using the PrntScrn utility. The capture 
operation can be initiated from the keyboard (by 
pressing the print-screen key), from the mouse, or 
from another program. The captured image area 
can be the entire screen, current active window, 
current active client area, selected window, selected 
client area, or specified rectangular area. Disk file 
formats include PM Metafile, PM Bit Map, PCX, 
TIFF, GIF, and WPG. The "Color Mapping" 
feature provides the control needed to produce 
quality printed images from color screen images. 
PrntScrn has clipboard Viewing, Printing, 
Exporting, & Importing capabilities for Bit Maps, 
Metafiles, and Text files. PrntScrn includes a 
Screen Blanker and a digital Date & Time 
"information bar". PrntScrn is priced at $115 and 
is available from major software resellers, 
or contact MITNOR Software. 


JHmSTAR PM Editor 


Do you need an Editor that has ... ? 


$99 


Presentation Manager support: Full SAA/CUA PM Multi Document Interface. Complete column, 
block and line cutting and pasting from the keyboard or mouse. OS/2 2.0 & 1.3 compatible. 

Power, Safety and Speed : Unlimited file sizes, Unlimited UNDO/REDO, and Unlimited number of 
open files and windows. Complete threaded compiles and error steppping integrated in the editor. 

BRIEF Compatible and Configurable: If you use BRIEF you'll feel right at home; a complete 
BRIEF keyboard compatible layout is included. Powerful keystroke macros and configuration options 
are available for your own customizations of the editor and keyboard. 

DLL version available: Do you need an editor to embed into your applications? This is perfect for 
vertical applications and OEMs that do not have the time to reinvent the wheel. Call for details. 

Valued Priced: The $99 special is valid till October 15, 1992. Then normal $129 list applies. 


Then you need to Call... 

RimSTAR Technology 32 Hawkes St. Marblehead, MA 01945. 617-631-7398 





















































GUI Tool for 
Professional Developers 


Advisory Plant and Environmental Control System 
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Courtesy of Electric Power Research Institute and Praxis Engineers, Inc. 






So you’d like to develop serious applications, but 
you haven’t found your ideal GUI tool for OS/2? 

GUILD is for YOU! 


® Productive. Point & click screens, actions and data. 

® Flexible. Open architecture for custom C/C++ coding. 
® Portable. Port across Windows, OS/2, Motif and Mac. 


(415) 593-3200 

Phone 

(415) 595-8158 
FAX 


« GUILD 

PRODUCTS INCORPORATED 


1301 Shoreway Road, Belmont, Calif. 94002 

Trademarks and registered trademarks belong to their respective holders. 



























































































































































































































The Power of Graphical Development 
In an Exciting New Environment 


Over three years of development and testing have 
transformed a vision into reality. An ideal develop¬ 
ment environment created by the perfect harmony 
of proven database technology within an exciting 
new visual landscape. Information Builders introduces 
PM/FOCUS, a graphical development and decision 
support system combining unparalleled data access 
and reporting with the versatility, stability and power 
of OS/2 2.0. 

PM/FOCUS offers a rich graphical tool set com¬ 
plete with File Painter, Forms Painter, and Query 
Painter to build even the most complex applications 
without writing code. Application components such 
as databases, forms, and procedures, become simple 
graphic objects that can be manipulated and activated 
with a point, click, and drag of your mouse. The 
comprehensive array of list boxes, check boxes, 
multiple fonts, radio buttons and other graphical 


images, offer an intuitive interface that’s remarkably 
attractive and easy to use. PM/FOCUS comes with 
its own proven database engine. Optional interfaces 
let you create sensational GUI applications for most 
other popular SQL databases. And PM/FOCUS is 
EDA/SQL enabled. This means you can have 
access to over 50 relational and non-relational file 
types on more than 35 different operating platforms. 

PM/FOCUS. It could well be the reason why OS/2 
was invented. Call your local Information Builders 
branch office or Micro Products Telesales at 
1-800-969-INFO. FAX (212) 695-3247. 

I TRTpm/focus 

Information Builders, Inc 

1250 Broadway, New York, NY 10001 






















Let Gpf write the GDI you design 


Gpf 


SYSTEMS, INC. 


Using the powerful point and click visual programming environment of Gpf*, you can 
prototype, test and generate a complete OS/2 PM GUI in a few hours or days rather 
than the weeks or months required to hand code the same design. Even a relatively 
simple GUI can require writing thousands of lines of code, but with Gpf you simply 
draw your user interface on the screen. The integrated dialogue editor of Gpf permits 
actions and context sensitive help to be linked to controls as you create them. Gpf then 
generates error free ANSI C complete with embedded SQL statements. 

Gpf is optimized to take full advantage of OS/2 PM, the most powerful and robust GUI 
system available. Since Gpf code directly accesses the PM API, there is no run time 
module to distribute with your application and no added overhead or royalties. 

Gpf keeps the entire design definition in one file. This means single point mainte¬ 
nance for easy update and archiving. From this file Gpf generates the C source file 
as well as .H, .RC, .IPF, DEF, .IDS, .MAK, etc.. 


Gpf supports: 

• Simple and direct linkage of the interface to program logic, built 
in or user defined functions. 

• Direct association of help screes with controls, and complete 
integration into the PM Help Presentation Facility. 

• Flexible use of Presentation objects (fonts, colors, etc.) with 
controls and windows (client area and frame). 

• Simple inclusion of bitmaps for use on About screens, user- 
defined buttons, and menu or pulldown entries. 

• Automatic embedded SQL statements to read OS/2 DataBase 
Manager tables, directly into combo or list boxes. 

• Multi-thread programming. 

• Multiple source file generation. 

• Automatic creation of controls that scale with window size. 

• Inclusion of user defined controls 


Try us out. 

Order Gpf today for just $995." 

Call Gpf Systems Inc. at: 

(203) 873-3300 or (800) 831-0017 - fax (203) 873-3302. 

Free demo software available 

P.O. Box 414, 30 Falls Rd., Moodus, CT 06469 

* GUI Programming Facility 











